Post Job Free
Sign in

System Computer Science

Location:
Princeton, NJ
Posted:
January 27, 2013

Contact this candidate

Resume:

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.



Contact this candidate