An Architecture for the Evolution of Web Applications
Paulo Caroli Carlos Jos P. de Lucena Marcus Fontoura
Computer Science Department Computer Science Department Computer Science Department
PUC-Rio, R. Marqu s de S. Vicente, PUC-Rio, R. Marqu s de S. Vicente, Princeton University, 35 Olden Street,
225, Rio de Janeiro, RJ, Brazil, 225, Rio de Janeiro, RJ, Brazil, Princeton, New Jersey, USA, 08544
22453-900
22453-900 *********@***.***
******@***.***-***.**
******@***.***.***-***.**
responsible for selecting the required information and converting it
ABSTRACT
to an appropriate format. One of the main responsibilities of the
This work presents a software architecture that is especially
interface-business broker is the conversion between strings that
useful for managing the evolution of web applications. Web-based
come from web forms into business objects that will handle the
systems are a range of applications for which there are no
HTTP request. The business-persistency broker is responsible for
technological standards and new concepts and tools are currently
manipulating persistent data to fulfill requests from business
under evolution. Examples of this lack of standards include the
objects.
transition from CGI scripts to Java Servlets and to Java Server
Pages (JSP). Therefore, the maintenance and evolution of web Layers
applications is an important topic for software developers and the
Interface
Blackboard
software research community. The proposed architecture
Blackboard
combines the n-tier, broker, and blackboard architectural patterns.
Module
Broker Interface - Business
1. THE ARCHITECTURE Business
A 3-layered architecture [1] separates the system functionality
into user interface, business logic, and persistency. Brokers [4]
Broker
encapsulate the interface between layers. Finally, a blackboard Business - Persistency
class repository models entities that do not naturally belong to Persistency
any of the three layers. Figure 1 abstractly illustrates this hybrid
architecture.
The interface layer is responsible only for validating the user Figure 1. The architecture
interface input (e.g. verifying if all required fields have been Classes that do not belong to neither the three layers nor the
provided). It does not perform any business operation. brokers are placed in the blackboard module. These classes model
Technologies generally used in this layer include HTML, Java real-world objects, such as employees and managers. Generally
Servlets, and JSP. they represent persistent information and are used in the business-
persistency communication protocol.
The business layer models the business logic, independently from
the access interfaces and persistency models. This layer focuses This architecture separates data from functionality: the data is
on the system behavior the business rules and not on the data provided by the blackboard classes while each of the three layers
being manipulated, which is modeled by blackboard classes. provides the appropriate functionality. Another important aspect
is data conversion. In general the business layer and the blackboard
The persistency layer is responsible for the physical storage of
will be implemented using OO technology (e.g. Java) while the
the data. It may use a wide variety of persistency models, from
interface and persistency layers may use other approaches (e.g.
flat files to complex frameworks for handling heterogeneous
events and relational databases). The brokers are the entities that
databases [3].
should make the appropriate conversions, making the interlayer
The brokers that implement the interlayer communication are communication independent of the technologies used to implement
each layer.
Permission to make digital or hard copies of all or part of this work
The loose-coupled nature of this architecture makes it possible to
for personal or classroom use is granted without fee provided that
evolve each layer independently from the others. This is
copies are not made or distributed for profit or commercial
especially useful for web applications, for which new techniques
advantage and that copies bear this notice and the full citation on
and tools are released constantly and no standards are defined yet.
the first page. To copy otherwise, or republish, to post on servers
or to redistribute to lists, requires prior specific permission and/or a Figure 2 illustrates abstractly the evolution of an access control
fee.
OOPSLA 2000 Companion Minneapolis, Minnesota
system [2]. It was first developed with Java Servlets as the user Performance issues: since the system is well organized,
interface and flat files as the persistency model. A second version performance bottlenecks can be more easily identified.
of the system was then developed with JSP and relational Moreover, optimizations are confined to specific layers;
database. The architecture allowed no changes to be made to the Management issues: aspects such as team division, code
business layer and blackboard classes, when evolving the system. ownership, cost control, and progress measurement, are also
better implemented when a well-defined architecture is used.
Version 1 Version 2
Business
Interface
I nterface
Servlets JSP
Blackboard Blackboard
Module Module
Interface - Business Interface - Business
Business - Pers. System Wrapper
Business Business
Persistency Persistency
Business - Persistency Business - Persistency
Persistency Persistency
Relational
Flat Files Database
Legacy
System
Figure 2. System evolution example
Database
2. OBSERVED ADVANTAGES
We have successfully applied this architecture to several large Figure 3. Legacy system integration
web-based systems [2]. These experiments have shown us some
3. CONCLUSIONS AND FUTURE WORK
advantages of this approach, which include:
Several case studies have shown that the proposed architecture is
Database changes: within the proposed architecture, changes
effective for the development of web-based applications [2]. It
on the data model require modifications only on the
accommodates drastic changes to the data and user interface
persistence layer, the business-persistency broker, and on the
models smoothly. It also allows for better development practices.
blackboard data classes. In the case that business logic and
interface are mixed with the persistency code, any changes in We plan to extend UML case tools to support the proposed
the data model may require changes of several parts of the architecture directly. One approach to do that is to mark
system. In the case of a drastic change (e.g. changing from architectural information in UML class diagrams, and use this
relational to OO database systems) the complete redesign of information to generate code with respect to the architecture. We
the system may be required; have already started this work using Rational Rose
(http://www.rational.com/products/rose) as the UML case tool.
Interface changes: changes are confined to the interface layer
and to the interface-business broker (e.g. changing from a Java
4. ACKNOWLEDGMENTS
Servlet to a JSP solution should not result in a general
We would like to thank Prof. Sergio Carvalho (in memorian) for
reengineering of the system - the business layer, persistency
his immense contribution to this work.
layer, business-persistency broker and blackboard should
remain the same);
5. REFERENCES
Legacy system integration: legacy systems can be treated as
[1] F. Buschman, R. Meunier, P. Sommerlad, and M. Stal,
data repositories, and their integration with the rest of the
Pattern-Oriented Software Architecture, A system of Patterns,
system can be made through specific business-persistency
John Wiley & Sons, 1996
brokers that act as system wrappers. Figure 3 illustrates this
situation; [2] P. Caroli, An Object-Oriented Methodology for Software
Projects, M.Sc. Dissertation, Computer Science Department,
Maintainability and evolution: addition (or elimination) of
Pontifical Catholic University of Rio de Janeiro (PUC-Rio),
features and changes of implementation technology are
1999 (in Portuguese).
facilitated through the use of the architecture, since changes
are encapsulated in layers and the system functionality is [3] E. Uch a and R. Melo, HEROS: A Framework for
well distributed in proper modules; Heterogeneous Database Systems Integration, in Proceedings
of the Tenth International Conference on Database and
Concurrency: the architecture allows better concurrency
Expert Systems Applications (DEXA 99), LNCS 1677, 656-
control, due to the low granularity of data and functionality
667, Springer-Verlag, Florence, Italy, 1999.
(e.g. access policies for handling data concurrent requests
may be encapsulated on the blackboard module); [4] M. Shaw and D. Garlan, Software Architecture - Perspectives
on an Emerging Discipline, Prentice Hall, 1996.