OACS – A Framework for Web Applications

Rafael A. Calvo, David Peterson
Web Engineering Group
The University of Sydney

1. Introduction

Engineering web applications is an increasingly complex challenge, with compressed life cycles [13], multidisciplinary teams [1] and all the risks involved in building large systems. Software engineering practices and techniques can be used to deal with some of these issues by improving reusability [1], modularity and extensibility. Application Frameworks are some of the engineering artefacts created to improve reusability of design and implementation. They consist of a modular and extensible architecture that allows for the long term costs of maintaining a system to be reduced.

Application frameworks often spawn from a particular need within a well-defined domain. The OACS framework is based on the former Arsdigita Community System (ACS) which was developed to solve the problem of creating scalable web community systems. ACS was first released in 1997 by Philip Greenspun and others in an attempt to achieve software reuse across a number of community website developments with similar business requirements and use cases. An early application of ACS was the development of photo.net, a popular community website for amateur and professional photographers. The implementation of photo.net is described in depth in two books by Greenspun [9,10].

In 1997, ArsDigita Corporation was launched to develop community websites for commercial customers and to further the development of the ACS platform. ArsDigita Corporation chose to release ACS as open-source software [9], making the software available under the terms of the GNU Public Licence (GPL) [8]. ArsDigita Corporation clients included Oracle, Siemens, MIT’s Sloan School of Management and the World Bank. In 2002 ArsDigita was bought by RedHat.
The initial ACS platform was implemented on the AOLserver web server using the Tcl programming language and the Oracle RDBMS. At this same time, the OACS project was commenced by a number of developers seeking to implement a version of ACS that would run on an Open Source RDBMS.

By 2000, ArsDigita Corporation was in a stage of rapid growth and during 2001 changed its strategy and started focusing on a new application framework fully developed in Java. With this change, OACS became ArsDigita’s code base for its ACS Tcl system. Today OACS is a mature project in its own right, with over 4000 members and 10 companies that provide commercial support and development. The most recent version, OACS 4.5b, will be released in March 2002. The framework is being used by a number of organizations, including Greenpeace and MIT’s Sloan School of Management. OACS 3.x has a much larger user base. This article will discuss OACS 4.5b architecture unless otherwise specified . The OACS 4.5b architecture is not dependent on any particular RDBMS, and it already operates with either Oracle or Postgres, with the ability to extend operation to other ACID-compliant databases in the future, if required.

In this paper we describe the OACS application framework, an open source system (licensed under the GNU Public License) that began as a spin-off of the ArsDigita Community System. Section 2 of the paper reviews some of the loosely defined concepts in application frameworks and looks at a suite of criteria for evaluating object orientated enterprise frameworks. Section 3 describes the OACS 4.5b architecture, its request processing mechanism, its permission and template systems. Section 4 evaluates the framework against established criteria. Section 5 concludes the discussion.

2. Application Frameworks

An application framework [2] may be defined as a reusable, “semi-complete” application that can be specialized to produce custom applications. Application frameworks provide a number of benefits to application developers including modularity, reusability, extensibility and inversion of control. Application frameworks may be general in focus, or developed to solve the specific challenges of a particular application domain. We propose the term “web application framework” to describe these framework architectures specifically designed to meet the needs of a particular web application domain.

OACS falls into this latter category of application frameworks. OACS allows website developers to rapidly implement modular and extensible web applications, achieving significant levels of software reuse by utilising the features of the core OACS packages.
Fayad et al. propose a suite of criteria [3] for evaluating object orientated enterprise frameworks that is useful in evaluating the success of OACS as a web application framework. Relevant criteria include:

• maturity of runtime functionality
  
• support for extensibility
  
• tailorability and customisability
  
• the catalogue of business objects (BOs) and enduring business themes (EBTs)
  
• a workflow management metaphor and enduring business processes (EBPs)
  
• software stability
  
• support for distributed objects and scalability
  
• platform independence or portability
  
• the capability to integrate with other frameworks
  
• maturity of framework documentation
  
• web-readiness
  
• a sound economic basis for selection.

In the remainder of the paper, we will examine the OACS framework architecture in depth and evaluate the performance of the OACS framework according to the enterprise framework criteria identified above.

3. OACS Architecture

The OACS framework is mostly implemented in Tcl as a set of applications that interact with AOLserver and a RDBMS (as of today Oracle or Postgres). It can be divided into a number of core packages, services and applications. Figure 1 shows this architecture.
The core packages are those that are required in order for OACS to function. They include a kernel, package management, administration utilities (users, sitemap, and other common business objects), a template system that cleanly separates business logic from presentation, and a backend mail and messaging system. Services such as the events package are implementations of reusable logic that is not application dependent and does not require a user interface. Application packages have a user interface and their code is clearly divided into application and presentation logic.

Figure 1: OACS architecture

Each service and application requires a data model that will be integrated into the framework. The integration of these data models enables reusability and a number of functionalities. To increase reusability the framework has an object oriented architecture but, since the RDBMS does not implement OO functionalities, they must be added ad-hoc by the framework. The OACS objects have their attributes stored in tables and a set of methods defined as PL/SQL packages. These packages hold the procedures that make the programming interface for the data model.

The idea behind the OO architecture of OACS is that each piece of information that might be reusable should be an object. Since RDBMS are inherently not OO, data structures are integrated into the framework by being added to an acs_objects table that keeps track of every OACS object. Another table called acs_object, defines the standard attributes stored on every object, including a system wide unique ID, an object type and auditing columns. The concept of OACS object types is equivalent to classes in OO programming languages, regrettably since we are using a RDBMS additional work must be performed.

Although reusability is the main goal, thanks to this design, a permission system can help the developer track which users are allowed to do what to the rows in the application table. Every object has an attribute called context_id used to specify the default permissions for an object and its intended scope.

Object types are defined with attributes defined in acs_object_types and acs_attributes. Object types in OACS can inherit attributes from a parent type, so the type system is hierarchical. Again because OACS data model is implemented on a RDBMS this inheritance needs to be made explicit.

Using the OACS objects systems requires four steps, all of which are implemented with the data model of application:
1. Create object type, most will be subtype of acs_object
2. Create object’s attributes
3. Create object’s methods
4. Create object’s data table.
An OACS application will also require the business and the presentation logic. OACS 4.5b uses a template system to clearly separate these two into different sets of files. One standard subdirectory (www) is used, where every user visible page is saved in at least two distinct files. The .tcl files have the tcl and SQL queries that act as data sources, as well as the name/value bindings. The .adp embeds these values in HTML by using a set of special tags and data source substitutions.

Many applications will require administration logic and UI, and they will be separated from the rest in another directory (admin). An OACS application also requires documentation saved in a third distinct directory (doc). The HTML files there will be managed by a centralized documentation system.

Finally, a complete package can be treated as another object in the OACS object system, this means that many instances of the same package can be installed in the same website. For example, a calendar package can be instantiated for different communities on a website: /community1/calendar, /community2/calendar, … /communityN/calendar. The website could be using N different calendar instances (e.g. one for each community), that have separate data but a single code base.

3.1 Request Processing

The purpose of a Web Application Framework is to dynamically process user requests to a web server. Since these functionalities are a hot spot [12] for the system they are integrated into a Request Processor (RP) that manages each request. Figure 2, shows a simplified sequence diagram of how the OACS Request Processor manages the request for a page.
Site Map. The RP maps the URL to a physical file. This is done by searching over the sitemap data model that maps URLs to an instance of an application.
Authentication. The RP examines session information sent by the client’s browser using cookies. The RP then sets up new session tokens if necessary.
Authorization. Once the user has been authenticated, the RP checks if the user has access permission for the requested file/object. The access control is handled by the permissions system.
URL processing. The RP searches for the file to be served. Depending on the extension, the file could be served directly (.html) or sent to the template system (.adp) or the tcl interpreter (tcl).

3.2 Permissions System

OACS has a powerful permissions system that manages access control in applications. It consists of three separate mechanisms. The first one defines groups of parties, as hierarchical organizations of users and other groups. For example a group of users “staff” could have access to the intranet portal, and groups of users within “staff” could have access to particular applications (e.g. fora).
The second mechanism defines the permissions data model, and implements a hierarchy of user rights. It defines read, write, create, delete and admin privileges for each object in the OACS system.

Finally, the contexts mechanism enables a hierarchy of default permissions, so administrators do not have to manually assign each of them. For example, a posting in an OACS forum is an object in its own right, so it can have any of the privileges defined in the permissions data model. Managing permissions at that level of detail would be unrealistic, so it is logical to have the system assume that the posting inherits the permissions of the whole b-board.

3.3 Template System

One of the big challenges involved in web production is the need for interdisciplinary teams, which can include graphic designers, engineers and other professionals working very closely. Thus, it is very important to build frameworks that take into account the needs of the production process. The OACS template system allows developers to separate the business logic (application) from the display logic, helping engineers and designers work more independently. All the code for managing the database and application state is separated from the code used to implement the logic of the display. Every user visible page has two files. The first one is a tcl script that sets the name/value bindings, called data sources. Data sources are made of database queries and Tcl processing. The second one uses these data sources via a set of special template related tags embedded in an HTML document.

4. OACS Evaluation

OACS primary benefits, as in other application frameworks [4] stem form the key features of: modularity, reusability, extensibility and inversion of control (via the dispatch/execution model of the Request Processor).
In order to assess the success of OACS as a web application framework, we present the following qualitative assessment against the enterprise framework criteria cited in the ‘Application Framework’ section of this document. Due to the lack of enough production sites built using OACS 4.5b, the assessment draws on experience with ACS and OACS 3.x as well.

Figure 1 – OACS Evaluation against Enterprise Framework Criteria

Detailed rationale for each item:

• Mature Runtime Functionality – Like many mature frameworks, OACS has benefited from a number of iterations (both as OACS and earlier as ACS) that have served to solidify key elements of the framework’s architectural design and have allowed a sophisticated suite of framework packages to evolve which address the specific needs of the community website application domain.
  
• Support for Extensibility, Tailorability and Customisability – OACS modular architecture makes it extensible, by having applications that can be independent from each other. The look and feel of a website can easily be modified using the template system customizing each application to particular requirements. OACS implements an OO-esque inheritance hierarchy using RDBMS fields and data models. OACS also has the ability to extend packages, and to mount multiple instances of packages throughout the web application.
  
• Catalogue of Enduring Business Themes (EBTs) and Business Objects (BO)[7] - EBTs are those concepts of a system that would remain constant over time. Business Objects also remain constant but may have internal processes that change. These software engineering artefacts are used to improve engineering practices through changing requirements.
  
• Workflow Management Metaphor and Enduring Business Themes – OACS possesses a powerful workflow environment (acs-workflow) based on the way it allows community website business processes to be modelled and implemented. Furthermore, the availability of so many available packages (eg. b-board, calendar…) serves to further demonstrate the extent to which the enduring business themes (EBTs) for this domain have been captured in the framework architecture. Therefore, OACS succeeds strongly in this regard.
  
• Software stability – Stability in the application framework, means that small changes in the requirements do not produce a ripple effect in required changes in the code. This is an important long-term requirement of any application framework. The design standards in OACS have been carried on from the ArsDigita’s strategy, but in reality each package has its own level of analysis. The data models for the core packages have been tested and thoroughly evaluated by the community, so in this sense we expect them to be stable. Although not analysed explicitly, as proposed in [7] BOs and EBT are taken into account.
  
• Platform independence – Since all the components of OACS are open source, they can, in principle, be ported to any other platform. The new OACS 4.5b architecture and its RDBMS independence is a great improvement over OACS and ACS 3x. OACS still relies strongly on AOLserver, although limited support exists for running OACS 3.x and 4.5b under the more popular Apache web server, with the use of the mod_nsd and mod_aolserver Apache modules. In our view, if OACS had a stable Apache integration it would broaden the OACS user base. AOLserver itself has been ported to a number of platforms. OACS runs on multiple operating systems including Solaris, Linux and Windows (the latter being allegedly less stable).
  
• Integration with 3rd party, legacy and other AF components – Integration with SAP was provided with ACS 3.x. Integration with billing systems is well developed in OACS 4.5b. It is still an open issue as to what kind of support for CORBA, RMI/RPC, SOAP type bindings will be provided in future versions of OACS.
  
• Mature Framework Documentation – This is inherited from ACS, but OACS community will have to make sure this key advantage is carried through to OACS 4.5b
  
• Web-readiness – OACS is a web application framework designed specifically for interaction with users via the web environment.
  
• Economics - Development of the ACS/OACS framework has been driven by economic concerns to build a reusable framework for web application development. OACS is an economically practical choice today because it is both free (libre) and free (gratuit), and because a speed-up in development time is obtained by using/extending from core OACS packages
  

5. Conclusion and future work

An application framework is defined as a reusable, “semi-complete” application that can be specialized to produce custom applications. Application frameworks are designed to improve modularity, reusability, extensibility and inversion of control. Web application frameworks are framework architectures specifically designed to meet the needs of a particular web application domain. In this paper we have described the OACS web application framework.

In a qualitative manner we show that OACS succeeds in a number of areas as a Web Application Framework. These assessment measures need to be formalized in order to make them more reproducible, and then applied to other web application frameworks. With regards to OACS, further work needs to be done on multi-platform support for other web servers other than AOLserver, maintaining framework documentation, and third party framework and web integration issues, in order to further strengthen its appeal and widespread use.

Acknowledgements.

This work would not have been possible without the valuable assistance of the OACS community.

References

1. Biggerstaff T. and Perlis A. “Software Reusability”. ACM Press/ Addison Wesley, 1989.
2. Calvo, R. A. “Introduction to e-commerce systems”. Pearson Education 2002.
3. Cline M, Girou M. and Young H. Enduring Business Themes (EBTs), sideline in Building Application Frameworks: Object-oriented foundations of framework design, M. Fayad, D. Schmidt R. Johnson Eds. John Wiley and Sons 1999.
4. Fayad, M., D. Schmidt, and Johnson, R Eds., Building Application Frameworks : Object-oriented foundations of framework design, John Wiley and Sons 1999.
5. Fayad, Mohamed E. and Schmidt, Douglas C. Object-Oriented Application Frameworks, Commun. ACM 40, 10 (Oct. 1997), 32-38.
6. Fayad, Mohamed E., Hamu, David S. and Brugali, Davide. Enterprise Frameworks Characteristics, Criteria and Challenges, Commun. ACM 43, 10 (Oct. 2000), 39-46.
7. Fayad M. and A. Altman. An Introduction to Software Stability. Commun. ACM Vol 44, 95-98
8. GNU project website: www.gnu.org
9. Greenspun, P. Phil and Alex’s Guide to Web Publishing. Morgan Kauffman 1999.
10. Greenspun, P. Database Backed Web Sites. Ziff Davis, 1997.
11. OACS Documentation [http://www.OACS.org]
12. Pree, W/ “Meta Patterns – A means for capturing the essentials of reusable obeject oriented design”. Proceedings of the 8th European Conference on Object Oriented Programming. Bologna, Italy July 1994.
13. Roberts J. “User requirements in software development”. Software Engineering Australia. April 2002.
14. ACS Developers Guide [http://www.arsdigita.com]