Web-Application Development Using the Model/View/Controller Design Pattern

Avraham Leff, James T. Rayfield

IBM T. J. Watson Research Center
{avraham,jtray}@us.ibm.com

Abstract face. The Model is the portion of the application that con-
tains both the information represented by the View and the
The Model/View/Controller design pattern is very useful logic that changes this information in response to user
for architecting interactive software systems. This design interaction. The PAC design pattern similarly decouples
pattern is partition-independent, because it is expressed in the application's information from the user interface. Here,
terms of an interactive application running in a single the MVC's View and Controller are combined into a Pre-
address space. Applying the Model/View/Controller sentation; the application's data is termed the Abstraction
design pattern to web-applications is therefore component; and the Control component is responsible for
complicated by the fact that current technologies communication between the decoupled Presentation and
encourage developers to partition the application as early Abstraction components. Use of the MVC and PAC
as in the design phase. Subsequent changes to that design pattern makes it easier to develop and maintain an
partitioning require considerable changes to the application since:
application's implementation -- despite the fact that the
application logic has not changed. This paper introduces • the application's "look" can be drastically changed
the concept of Flexible Web-Application Partitioning, a without changing data structures and business logic.
programming model and implementation infrastructure, • the application can easily maintain different inter-
that allows developers to apply the Model/View/Controller faces, such as multiple languages, or different sets of user
design pattern in a partition-independent manner. permissions.
Applications are developed and tested in a single address-
space; they can then be deployed to various client/server Colloquially (e.g., [3]), the term "MVC" has been
architectures without changing the application's source extended to describe the way that large-scale changes to an
code. In addition, partitioning decisions can be changed application's Model are driven by a Controller that is
without modifying the application. responsible, not only for accepting and processing user
interactions, but for logic that changes an application's
1. Introduction overall state in response to the event created by the user's
interaction. In response to changes in the Model, the Con-
troller initiates creation of the application's new View.
1.1. The Model/View/Controller Design This paper uses the term MVC in this, more general and
Pattern "PAC-like", sense of architecting an application so that
business logic, presentation logic, and request processing
The well-known Model/View/Controller[12][5] (or are deliberately separated.
MVC) design pattern is a useful way to architect interac-
tive software systems. Also known as the Presentation/ 1.2. Web-Applications and the MVC Design
Abstraction/Control[6] (or PAC) design pattern, the key Pattern
idea is to separate user interfaces from the underlying data
represented by the user interface. The "classic" MVC Web-applications, like other interactive software sys-
design pattern actually applies to low-level user interac- tems, can benefit by being architected with the MVC
tion such as individual keystrokes or activation of mouse design pattern. For example, one "all Java" approach uses
buttons. In MVC, the View displays information to the Entity Enterprise JavaBeans (EJBs [7]) as the Model, con-
user and, together with the Controller which processes the structs the View through HTML and JavaServer Pages,
user's interaction, comprises the application's user inter-
and implements the Controllers through Servlets and Ses- View is resident on the client; the Controllers (excluding
sion EJBs. the actual window screen controls) and the Model are resi-
dent on the server. When deployed as a fat-client, the web-
The problem with using the MVC design pattern to application's Model and Controllers are also resident on
develop web-applications arises from the fact that web- the client. Technology choices, in other words, mean that
applications are intrinsically partitioned between the client developers may not be able to make the right partitioning
and the server. The View, of course, is displayed on the decisions -- even if they know what the right decision is.
client; but the Model and Controller can (theoretically) be
partitioned in any number of ways between the client and To summarize, web-applications can certainly use the
server. The developer is forced to partition the web-appli- MVC design pattern when:
cation "up-front" -- certainly at the implementation stage, • the correct partitioning is known and
and often as early as the design phase. In contrast, MVC is
partition-independent: i.e., the Model, View, and Control-
• the available technology infrastructure is compati-
ler reside and execute in a single-address space in which ble with that partitioning.
partitioning issues do not arise. Partition-independence is
In practice, developers simplify the problem by mak-
one of MVC's features since location-dependent issues
ing a priori assumptions about the technology and parti-
should not drive architecture or design decisions. Unfortu-
tioning solution. This approach is discussed in more detail
nately, partitioning implies that web-applications are loca-
later (Section 3.2.3).
tion-dependent, and this characteristic means that it is
much harder to apply the MVC design pattern in the web-
We introduce the concept of Flexible Web-Applica-
application context.
tion Partitioning (or fwap) to enable web-applications to
use the MVC design pattern more naturally. Before dis-
Of course, developers can simply partition the web-
cussing fwap and other, related work, in Section 3, we first
application, deciding that method A will run on the server
provide a simple motivating example of web-application
and method B on the client. Once partitioning is done, the
partitioning in Section 2.
MVC design pattern can be applied, in parallel, to imple-
ment the client and server portions of the application. The
problem with this approach is that it is often impossible to 2. Partitioning a Web-Application:
make correct partitioning decisions early in the design Example
phase since these decisions depend on application require-
ments that change considerably over the course of the Picture a web-application that enables clients to get
project. The problem is made even more difficult by the information about a company's employees. We simplify
fact that the correct partitioning decision depends on static the example by allowing the client to perform only two
(e.g., relative power of client to server machines) and operations.
dynamic (e.g., network congestion) environmental factors.
1. By supplying a name, and clicking on a "search"
Applying the MVC design pattern in an environment
button, search the employee directory "by name". The
where the partitioning decision is not fixed is a difficult
search returns the set of employees that match the search
task.
criteria in a format that displays an abbreviated employee
record for each member of the returned set.
To make matters worse, "controller partitioning" is
2. By clicking on a "details?" button, get detailed
often not an independent, "tunable" feature of the develop-
information about a specific employee.
ment process. Rather than being a function only of the
web-application's intrinsic characteristics, partitioning
Implemention in a stand-alone, single address-space,
depends on technology decisions that have nothing to do
environment, is straightforward. From the perspective of
with the application. Take, for example, the "thin-client"
the MVC design pattern (see Figure 1):
versus "fat-client" dichotomy. Often, application develop-
ers are constrained in their choice of implementation tech- • The Model consists of the records in the employee
nologies. Perhaps they are told "applets are bad because directory.
they are heavy-weight and because of security concerns". • There are four Views: a "search" panel; a display of
Perhaps they are told "you can't build sophisticated views abbreviated information about a set of employee records; a
in HTML". Once technology selections are made, they display of detailed information about a specific employee;
greatly determine how the application will be partitioned. and a report that no employees match the search criteria.
When deployed as a thin-client, only the web-application's
 View Controller Model
Serial Number Name Phone
Query employee DB (Model)
Foreach employee in queryResult
Create "Detail" button 123456 Smith, John 555-1234
{ Create employee-name label
end

FIGURE 1. Model/View/Controller Representation of the Sample Application

• There are two Controllers: one that, given a typically consist of a preliminary search for an employee
"search" directive, drives the process of querying the using a "partial name", followed by request for more infor-
Model and returns a result set; and one that, given a mation after the specific employee is determined by
"details" directive, queries the Model to get the full set of inspection. Remember: this is only a motivating example!)
information about the specified employee.
Of course, what we really want is to do avoid parti-
However, implementation as a web-application in a tioning while implementing the application, since the cor-
client/server environment raises the issue of partitioning rect partitioning decision depends on factors that are not
which is conceptually orthogonal to, but in practice com- necessarily determined until actual deployment. For exam-
plicates, the MVC design pattern. Naively, as there are ple, if the employee directory is relatively small, the "fat-
two Controllers, the application can be implemented in client" approach with both Controllers executing on the
one of four ways. Either both Controllers execute exclu- client makes sense and would provide better performance.
sively on the client or server, or one Controller executes Conversely, if the application is deployed in a "internet"
on the client and the other executes on the server. Each environment in which users want minimal customization
partitioning decision greatly affects the way that the appli- of their environment, the "thin-client" approach may be
cation is implemented. For example, if both Controllers the only solution possible. Delaying application partition-
run on the client (the "fat-client" approach), the entire ing for as long as possible is even more attractive because
Model must be downloaded to the client -- which is often partitioning gets in the way of designing the Views and
impractical. If both Controllers run on the server (the developing the business logic needed by the Controllers.
"thin-client" approach), two round trips between client and Flexible web-application partitioning addresses these
server must be performed each time that the client needs. In fact, flexible web-application partitioning goes
searches for an employee and then asks for more detail further, allowing partitioning decisions to vary dynami-
about that employee. cally, during application execution.

In fact, for many environments, neither the thin-client The fwap programming model explictly supports the
or the fat-client is ideal. Instead, using a dual-mvc MVC design pattern, and enables programs executing in
approach [4], we partition the Controllers between the cli- smvc mode (Section 3.1) to execute in a single address-
ent and server. Specifically, the "search" Controller exe- space. When deployed, these programs can be flexibly
cutes on the server in association with a Model consisting partitioned without changing the source code used during
of the complete employee directory. However, when smvc development. We refer to such fwap applications as
returning relatively small sets of employee records, the fwaplications.
Controller also returns the full record for each of the
employees, so that they can be maintained in the client- 3. Flexible Web-Application Partitioning
side Model. The dual-mvc approach allows requests for
detailed employee information to be served by the client, Although web-applications must intrinsically deal
thus eliminating a client/server interaction. (This imple- with partitioning issues, Section 2 illustrates why it is pref-
mentation is beneficial only when application scenarios
erable to implement web-applications in a manner that is 3.2. Related Work
partition-independent. Partition-independence enables
developers to be flexible about partitioning, because it 3.2.1. View Specification and Generation. In order for
allows them to deal with changing technology infrastruc- Views to be rendered on different client platforms, they
tures, changing application characteristics, and even must be specified in a manner that is independent of plat-
changing environment conditions such as network conges- form-specific characteristics. One approach to this prob-
tion. The problem, of course, is how to maintain partition- lem [1] is to use XML as the basis of a universal,
independence given that web-applications are location- appliance-independent, markup language for user inter-
dependent. The fwap programming model, implementa- faces. Our approach differs only in that we use a Java API
tion, and infrastructure, enable developers to build web- to specify a library of GUI components and to construct
applications in precisely such a partition-independent Views out of these components. Then, at runtime, plat-
manner. Applications are developed and tested in a single- form-specific implementation libraries render the Views
address space; they can then be deployed to various client/ on the client device (e.g., using HTML for web-browsers).
server architectures without changing the application's We are not currently focusing on issues relating to how
source code. In addition, partitioning decisions can be such "canonical" Views should be rendered on devices
changed in without modifying the application. with considerably different form factors from desktop and
web-browser environments (e.g., PDAs and web-phones).
In order to provide partition-independence, fwap must
address a set of difficult problems. These problems 3.2.2. Controller Specification and Execution. Because
involve partition-independent technologies for the individ- we want fwaplications to be deployable to the dual-mvc
ual Model, View, and Controller components of an appli- architecture, Controllers must be able to execute "as is" on
cation; integration of these components in a consistent the client as well as on the server. Since we code fwaplica-
application programming model; and the construction of tion Controllers to the Java Virtual Machine, this excludes
transforms that map the partition-independent representa- a number of client platforms as fwaplication deployment
tion of an application to a partitioned application running platforms. PDAs and web-phones, for example, may not
on actual client/server platforms. We are currently focus- support the JVM -- although we do expect J2ME [11] to
ing our efforts on enabling fwap to support a variety of increasingly enable such devices to support Java applica-
deployment architectures. In order to make progress on tions. Even in the case of web-browsers, the requirement
this front, we have made certain simplifying assumptions of device independence (e.g., Microsoft Internet Explorer
that allow us to avoid some of the above problems for the versus Netscape Navigator) implies that it might better to
moment. We discuss these assumptions below (Section write Controller in JavaScript [9] than in Java. At present,
3.2). we simplify the problem of "single source" Controller
specification by using the Java Plug-in [8]: this allows
3.1. fwap Architectures standard web-browsers to run applications written to the
JDK 1.2 libraries.
fwap supports the following architectures:
• single-mvc (or smvc), which serves as the fwap 3.2.3. Thin-Client Presentation Frameworks. It is
development architecture. The smvc architecture corre- important to note that a number of other projects
sponds to the classic MVC design pattern (e.g., Figure 1): [2][13][14] are also engaged in the application of the
the Model, View, and Controllers all reside and execute in Model/View/Controller design pattern to web-application
a single address space in which client-server and partition- development. The key contribution of fwap is its emphasis
ing issues do not arise. of partition-independence. In contrast, these other efforts
• thin-client, a deployment architecture in which the are explictly partition-dependent, and assume that web-
Model and Controllers reside and execute in a single applications are deployed to the thin-client architecture.
address space on the server, and generate the View that is
rendered on the client. These presentation frameworks are being developed
• dual-mvc (or dmvc), a deployment architecture [4] in the following context. The introduction of Java Servlets
in which Controllers and Model reside on both the client [10] in the late 1990s encouraged a style of web-applica-
and server. Either the client or server can generate the tion design in which servlet code generated Views through
View, as needed, to be displayed on the client. a series of println statements that wrote HTML to the
client's web browser. JavaServer Pages [3], introduced in
1999, inverted this paradigm by allowing developers to
embed scripting code (that accessed server-side Model and through the API, the fwap infrastructure can, for example,
Controller code) into HTML pages. Both of these transparently synchronize a stale server-side View with
approaches violate the MVC design pattern because they the current client-side View. Transparency is a basic
tend to inextricably mix View generation code with Con- requirement, since the fwap programming model pre-
troller and Model code. Thin-client presentation frame- cludes explicit code to transmit user input to the server.
works are being developed with the intention of Without this ability, a Controller repartitioned so that it
facilitating the use of MVC design pattern to build web- executes on the server rather than on the client, could not
applications. The basic idea is to use servlets and server- access the contents of an input field. The fwap infrastruc-
side JavaBeans as an application's Controllers (application ture ensures that Controller code, partitioned to run on the
logic); use EJBs to represent the Model and the business server, and accessing the View through getView, will
logic; and use JavaServer Pages to extract Model data and access up-to-date values.
generate Views. Individual frameworks emphasize differ-
ent issues. Thus, Barracuda uses a "push MVC" approach 3.3.2. Model. A fwaplication's Model follows the same
in which the Model knows about, and is responsible for principles as a fwaplication's View: components are speci-
generating the View; WebWork and Struts use a "pull fied by interface, and components are accessed only via a
MVC" approach in which the View accesses the Model as key-based API. Although many component models are
needed. Struts is more tightly coupled to the Servlet API suitable for fwaplications (e.g., COM or CORBA), the
than WebWork. fwap Model components follow the Enterprise JavaBeans
component specification [7].
Although fwaplications can also deploy to the thin-
client architecture, fwap emphasizes the ability to deploy 3.3.3. Controllers. In the fwap programming model, a
to the dual-mvc architecture so as to improve performance Controller is an functional unit that may be invoked to run
through client-side execution. As a result, fwap is con- on either the web-application client or on the server. The
cerned with issues, such as Model synchronization and actual location of a Controller's execution is determined
transparent Controller delegation, that are not of interest to by explicit directives in a controller deployment descrip-
the thin-client presentation frameworks. tor. This is in contrast to "utility" code that always exe-
cutes in the same address space as the caller. It also
3.3. fwap Programming Model contrasts to classic "client/server" code in which client
code must explictly call out of its address space to invoke
One way that the fwap infrastructure supports the pro- code on the server.
gramming model is by providing a base fwaplication inter-
face which specifies that every fwaplication is associated The first step in fwaplication development is to spec-
with a Model and View, each accessed through their own ify the set of methods (i.e., Controllers) that can be "flexi-
API. Web-applications are developed by supplying an bly partitioned". These methods comprise the interface
interface that extends the base fwaplication interface with extending the base fwaplication interface, supplied as part
application-specific methods. of the fwap infrastructure. A method can be "flexibly parti-
tioned" only if it's part of this application-specific inter-
3.3.1. View. fwap Views are composed from a suite of face. Note that these methods are not constrained to take
GUI components such as buttons and input text fields. The only user-interaction events as their input (as in "classic"
programmer can associate method invocations with user- Controllers). Rather, they may take arbitrary input and
interaction events (e.g., a button click) through the regis- return arbitrary output. For example, one well-known per-
terEvent method; the fwap infrastructure ensures that the formance optimization performs "syntactic" validation of
specified method executes when the event occurs. The user input on the client so that the client can immediately
GUI components are specified through interfaces; this reprompt the user for valid input if it detects a problem.
allows the implementation provided in the smvc develop- The client only sends the request to the server after the
ment infrastructure to be replaced by platform-specific user's input has been validated. This optimization is usu-
implementations when the application is deployed. ally implemented by JavaScript code running in a thin-cli-
ent browser which then sends the request to a Servlet after
Components are created, removed, and accessed only it has validated the user's input. In fwap terms, the pro-
through the fwap (key-based) API invoked against the grammer simply specifies two methods validate(...) and
fwaplication's getView method. The fwaplication may not process(...) in which validate calls process only if it deter-
directly refer to a component by storing a reference to the mines that the input is syntactically valid. At deployment,
component. Because components are accessed only the two methods can be partitioned so that validate runs on
 Server

HTTP HTML
Response View-generation
libraries
View
HTTP POST
Request
Query employee DB (Model)
Foreach employee in queryResult
Create "Detail" button
{ Create employee-name label
Controller end

Serial Number Name Phone

Model 123456 Smith, John 555-1234

Thin client
FIGURE 2. The Sample Application Deployed to the Thin-Client Architecture

the client, and transparently calls process which runs on 4.2. thin-client
the server.
Figure 2 shows how the MVC structure of the sample
3.4. Development application is deployed to the thin-client architecture.

fwaplication development consists of supplying an Using a factory-pattern, the Swing-based View imple-
implementation for the subclassed fwaplication interface. mentation of smvc mode is replaced by components that
Because this is completely application-specific, the fwap generate HTML that produce the equivalent View when
infrastructure provides no additional support for this rendered in a standard web-browser.
phase. Following the Model/View/Controller design pat-
tern, the programmer supplies the logic that generates the The fwaplication's .class files are installed in a
required Views, accesses the Model in order to generate standard web-server such as Tomcat, and made available
Views, and updates the Model as necessary. to web-clients by creating a corresponding servlet entry in
the web.xml file [10].
4. Current Implementation
A web-client's initial GET request to the URL desig-
nated in the servlet-mapping entry causes a controller
This section describes the status of the current imple-
servlet to:
mentation of the fwap programming model and infrastruc-
ture. • instantiate a new fwaplication instance that will be
associated with this client.
4.1. smvc • request that the fwaplication generate the initial
View. In thin-client deployment, this consists of a stream
The smvc View components are rendered using Java of HTML that will be rendered in the client's web-
Swing components, and the fwaplication is developed and browser.
tested as a stand-alone Swing application. • returns the HTML to the client.
 Client Server

View
Common path

Client-only path

Client-Server path
Thin client

Swing-based Nondisplaying
View-generation View
libraries libraries

FWAP Runtime
FWAP Runtime

Query employee DB (Model) Query employee DB (Model)

HTTP
Foreach employee in queryResult Foreach employee in queryResult
Create "Detail" button Create "Detail" button
{ Create employee-name label { Create employee-name label Controller
Controller
end end

Serial Number Name Phone Serial Number Name Phone

Model 123456 Smith, John 555-1234 123456 Smith, John 555-1234

Model

FIGURE 3. The Sample Application Deployed to the Dual-MVC Architecture

Because all fwaplications inherit the same lifecycle 4.3. dual-mvc
methods, the controller servlet is generic so that a single
instance can service all web requests to all installed fwa- One way to look at the current implementation of the
plications. dmvc deployment architecture is that two instances of the
smvc fwaplication implementation execute: one in the cli-
The web-client proceeds to interact with the fwaplica- ent, and one in the server. Figure 3 shows how the sample
tion's GUI precisely as in smvc mode, with the identical application of Figure 1 is deployed to the dual-mvc archi-
Controller and Model executing (on the server) as in smvc tecture. In order for the smvc fwaplication implementation
development. Each time that the user triggers an interac- to execute "as is" on a web-client, we deploy the client-
tion event (e.g., clicks a button), embedded (and generic) side fwaplication into a generic loader applet that runs in
JavaScript generates a POST request to the controller serv- the web-browser. An HTML file is associated with each
let. The request specifies the Controller invocation associ- type fwaplication. It specifies the name of the fwaplication
ated, through the registerEvent method, with this interface class; the location of the controller deployment
interaction event. Using reflection, the controller servlet descriptor file; and the URL through which the dmvc con-
invokes the specified method, which proceeds to execute troller servlet can be contacted. By using the Java Plug-in
precisely as it does when the user clicks a button in smvc [8], even standard web-browsers can run applications
mode. written to the JDK 1.2 libraries. As a result, the View and
Model code of a dmvc fwaplication are identical to the
code used in smvc mode.
 Coordination of the two activated fwaplication Serializing the View also involves serialization
instances is simplified by the following observation. of all "event handlers" (Controller invocations)
Although the purpose of the dmvc architecture is to enable associated with View components through the
Controller execution on either the client or server, dmvc registerEvent method. Although the user cannot
execution always proceeds serially, never in parallel. interact with the server-side View, the server-
When a user interaction with a GUI element triggers a side must include this information when it trans-
Controller execution, the Controller will execute only at fers control back to the client-side of the fwapli-
the location specified by the controller deployment cation.
descriptor. During the Controller's execution, fwaplication c. Serializing the values of the parameters passed
execution at the other location will not occur. to the Controller.
d. Using Java's ObjectInputStream and
However, the client-side fwaplication must be ObjectOutputStream classes, the client-side
enhanced with the ability to delegate Controller execution Model, View, and Controller parameters are
to the server when directed to do so by the controller passed to the dmvc controller servlet in an
deployment descriptor, or when the client requires Model HTTP POST request.
components that are available only on the server (see e. The controller servlet synchronizes the state of
Ongoing Work). We do this by having the client-side the server-side fwaplication with the client-side
implementation class extend the smvc, server-side, imple- Model and View.
mentation. f. Using Java dynamic invocation, the specified
Controller is invoked on the server-side fwapli-
The client-side implementation class overrides the cation instance. Recall that the server-side
smvc implementation of each Controller with the follow- implementation of the Controller is identical to
ing algorithm. the code used in smvc mode.
1. At runtime, access the controller deployment g. The return value, (possibly) updated server-side
descriptor to determine whether the Controller is to be Model, and new View (recall that Controller
executed locally (on the client), or remotely (delegated to execution is responsible for constructing the
the server). fwaplication's next View), are serialized and
2. Perform local execution by calling transmitted back to the client-side fwaplication
super.Method(...), i.e., by executing exactly the same code as the response to an HTTP POST request.
as in smvc mode. This is denoted by the "dashed arrow" 4. After its delegation to the server-side completes,
execution path in the client side of Figure 3. the client-side Controller updates the client-side Model to
3. Perform server-side execution (denoted by the reflect changes made to the server-side Model, "reconsti-
“dotted-arrow execution path of Figure 3) by: tutes" the new View as client-side GUI components, and
a. Serializing the client-side Model. renders the View for the user.
b. "Serializing" the client-side View. We do not
serialize the client-side GUI components which, 5. Ongoing Work
after all, encapsulate Java Swing components
that are meaningless to the server-side of the fwap is a work in progress, and we discuss here some
fwaplication. Instead, we serialize a "distilled" of the ongoing design issues and implementation that we
version of the client-side View, containing only are currently working on.
the property values of each component.
With respect to the smvc development architecture
The server-side requires access to the current and the thin-client architecture, the ongoing work focuses
View for two reasons. First, as in the thin-client on enriching the suite of View components. This relates
architecture, it needs to be aware of the state both to the types of components supported and the number
state changes caused by the user's interactions of properties provided by each type of component. The
with the client-side View. Second, the server- current framework and implementation, however, ade-
side will likely construct the next View in terms quately supports the Model/View/Controller design pat-
of changes to the current View: e.g., by leaving tern and deployment to a thin-client architecture. Our main
one panel unchanged, and replacing a second research focus is on the dmvc deployment architecture.
panel.
5.1. Model Synchronization The fwap infrastructure can transparently catch the
exception thrown when a cache miss occurs. At that point,
Currently, when synchronizing the client and server two possibilities exist:
portions of a deployed dmvc fwaplication, we simply copy • As the next cache "tier", ask the server-side Model
the entire set of Model components from one location to for the necessary Model component. (If the component is
the other. This is inefficient, since only components that not resident in the server's transient Model, it will perform
have changed state need to be synchronized. We are there- the required requests to persistent storage to bring the
fore working on the use of "dirty bit" techniques to elimi- component into the transient Model). Once the component
nate unnecessary Model synchronization operations. has been fetched into the client-side Model, proceed with
the client-side Controller execution.
5.2. Model Pre-Fetching • Cease client-side execution of the Controller, and
delegate execution to the server-side of the dmvc fwapli-
The basic motivation of the dmvc deployment archi- cation.
tecture is to provide web-clients with the ability to directly
service user requests rather than delegating requests to the The first approach, "cache miss recovery on the cli-
server. Currently, we simply load the entire Model into ent", makes sense when the Controller will not trigger
both the client and server portions of a dmvc fwaplication; many more cache misses. Otherwise, the overhead of con-
this trivially assures that the client will have the necessary tacting the server on a per-component basis will cause
Model components. Obviously, this approach does not considerable performance degradation. Conversely, the
scale beyond "proof of concept" applications. We are second approach, "cache miss recovery on the server",
therefore adding infrastructure hooks to allow fwaplica- makes sense in situations where the Controller will trigger
tion programmers to "pre-fetch" Model components from many more cache misses. As with Model pre-fetching,
the server side of a dmvc fwaplication to the client side. determining which approach is appropriate for a given
Once this is provided, fwaplication programmers can Controller greatly depends on the typical scenarios for a
study typical flows of their application to determine which specific application.
portions of the Model are best suited for client-side pro-
cessing. For example, the example of Section 2 assumes
6. Conclusion
that directory queries often proceed in two stages: first, a
broad query to retrieve a small set of possible employees
matches; second, a "drill down" request to get more infor- This paper describes how the partition-independent
mation about a specific employee from the first stage. Model/View/Controller design pattern can be used in the
Given such a scenario flow, it makes sense to pre-fetch the intrinsically location-dependent environment of parti-
"details" information when processing the initial broad tioned web-applications. Flexible web-application parti-
query; this allows client-side processing of the "drill tioning enables the code used to develop a stand-alone
down" request. However, if the result set of the broad application and in a single address-space, to be used (with-
query is too large, it will then be impractical (i.e., will out modification) in deployments to various client plat-
degrade performance) to pre-fetch the detail information forms and with any desired partitioning scheme.
for the result set.
fwap encourages an approach to web-application
deployment in which the application's "scenario flows" are
5.3. Dealing with Cache Misses
continuously studied to get insight about how clients actu-
ally use the application. By understanding the scenario
Because the client-side of a dmvc fwaplication con-
flows, the application can be partitioned in a way that
tains only transient Model components, it in effect serves
improves performance. In contrast, traditional implemen-
as a Model cache for the server. As a cache, the client-side
tation techniques require that such analysis be performed
Model must be able to deal with situation of a "cache
only in the design and requirements phase because it is
miss" -- i.e., where Controller execution requires a Model
much too costly to repartition the application once it is
component that is not resident on the client. (Note that
deployed. Unfortunately, the necessary insights can often
Model "pre-fetching", discussed above, is a technique
be made only after the application has been deployed and
used to reduce the number of cache misses. Even with per-
in production for some time. Repartitioning, under fwap,
fect knowledge, cache misses may occur since the client
imposes no extra cost; an application can therefore be
can cache only a portion of the server-side Model.)
readily tuned after deployment based on feedback from
actual client use.
 We are currently implementing the algorithms and 5. Buschmann, F. et al, Pattern-Oriented Software Architec-
infrastructure needed to enable fwaplications to scale over ture: A System of Patterns, John Wiley and Sons, 1996, 123-168.
non-trivial application Models. We are also working with 6. Coutaz, J., PAC, An Object-Oriented Model for Dialog
Design, Elsevier Science Publishers, Proceedings of Human-
a customer to validate the fwap concepts and implementa- Computer Interaction - INTERACT, 1987, 431-436.
tion. 7. Enterprise JavaBeans Specifications, http://java.sun.com/
products/ejb/docs.html, 2001.
7. References 8. JAVA PLUG-IN 1.2 SOFTWARE FAQ, http://java.sun.com/
products/plugin/1.2/plugin.faq.html , 2001.
9. Flanagan, David, JavaScript: The Definitive Guide, 3rd,
1. Abrams, M., Phanouriou, C., Batongbacal, A., Williams, S., O’Reilly, 1998.
Shuster, J., UIML: AnAppliance-Independent XML User Inter- 10. JAVA SERVLET TECHNOLOGY IMPLEMENTATIONS &
face Language, Proceedings of the Eight International World SPECIFICATIONS, http://java.sun.com/products/servlet/down-
Wide Web Conference, May, 1999, 617-630. load.html#specs , 2001.
2. Barracuda: Open Source Presentation Framework, http:// 11. Java 2 Platform, Micro Edition (J2ME), http://
barracuda.enhydra.org/, 2001. java.sun.com/j2me/, 2001.
3. Bergsten, Hans, JavaServer Pages, O’Reilly, 2000. 12. G.E. Krasner and S.T. Pope, A Cookbook for Using the
4. Betz, K., Leff, A., Rayfield, J., Developing Highly-Respon- Model-View-Controller User-Interface Paradigm in Smalltalk-
sive User Interfaces with DHTML and Servlets'', Proceedings of 80, SIGS Publication, 26-49, Journal of Object-Oriented Pro-
the 19th IEEE International Performance, Computing, and Com- gramming, August/September, 1988.
munications Conference -- IPCCC-2000, 2000. 13. Struts, http://jakarta.apache.org/struts/index.html, 2001.
14. WebWork, http://sourceforge.net/projects/webwork, 2001.