University of Pennsylvania
Core Administrative Systems
Architecture Recommendations

Last updated 13 December 2002

Summary

This document evaluates architectural alternatives for future core administrative systems. It argues that we need a clearly documented, preferred architectural framework for future enterprise applications, and a simpler alternative for "quick-hit" applications. Our recommended framework is J2EE (Java 2, Enterprise Edition), which provides the most promising combination of immediate usefulness, multiple-vendor support, and built-in support for emerging technologies like Web Services. As a first step in that direction, we recommend developing new enterprise applications using the Servlet/JSP technology of J2EE. (This has already been done for BenDeposits, which provides a working application structure that can be adapted to other situations.) The Servlet/JSP approach provides a consistent and logical upgrade path to a more robust J2EE implementation. For simpler implementations, where no cross-platform connections are needed, we recommend using an object-oriented PSP (PL/SQL Server Pages) approach. Architecturally, this is similar to JSP and will allow us to capitalize on the existing expertise of our staff.

Intro

In the last five years, technology has taken several sharp turns. We have moved irreversibly from a world where a single mainframe handles the bulk of application processing to a world where processing is shared across many platforms, operating systems, and database management systems. More recently the Web has become the focus of tremendous innovation. This is not a theoretical issue; it affects ISC in specific, concrete ways. To give a sense of the dimensions of the change, here is a list of some of the application environments we are currently supporting (in addition to the more traditional CICS and Natural environments):

• Java Server Pages
• PL/SQL Server Pages
• Oracle Forms and Reports
• Oracle WebDB
• Oracle Web Agent
• PHP

We support applications that run on a number of different web servers, including:

• Oracle IAS
• Apache
• WebSphere
• Netscape Enterprise Server

There are a number of database management systems involved as well. In addition to Adabas and Oracle, we have applications that use:

• mySQL
• FoxPro
• Microsoft Access
• Progress
• Ingres

One consequence of this proliferation is that we have a number of smaller applications with incompatible technology. Another is that our ability to support our applications is being spread thinner and thinner. To best serve our clients, we need expertise that is both broad and deep; the alternative is to hire expensive support on a temporary basis. We believe that the only way to maintain the necessary level of internal expertise is to choose a specific direction from the many paths that have become available to us. Focusing more intensively on a smaller tool set will reduce our training costs and increase our staffing flexibility.

We also believe that in order to continue to serve our clients effectively, we need to choose a direction that brings us closer to several emerging trends in Web technology. Those trends include:

• The use of "layered" system architecture, where data, business rules, and presentation are handled independently. In a layered environment, a change to the business rules would not require a rewrite of the presentation; if new forms of access become feasible — perhaps through hand-held computers or cell phones — they can be added to the presentation layer without affecting the overall architecture of the system.



• The use of middleware to handle real-time messaging between platforms and systems. At present, our only real form of communication between platforms is FTP: using a batch process to transfer a data file. Effective middleware would make it possible to access data — even Adabas on the mainframe — without using less robust approaches like "real-time batch" or screen-scraping. It would reduce the need for batch interfaces and improve the timeliness of data throughout AIT-supported applications.



• The use of Web "services," a modular, object-oriented architecture with published interfaces and directories, making it possible to assemble applications using "plug-in" components from different vendors.



• The use of XML as a tool for communicating data from one application to another.

It is time to leave behind the stage of experimenting with each new tool as it comes along, and move to a mature and well-documented architecture. The goal is not to create a rigid framework that every application must fit into; the goal is to create a set of guidelines that lead us, at a pace that is sustainable, to a more robust, more flexible, and more consistent environment.

Criteria for choosing an architectural framework

The following criteria are crucial in evaluating a new development environment:

• First and foremost, it should allow us to retain our focus on client service, by allowing us to rapidly deliver software that is flexible, modular, and scalable. (It should not be based on our desire to gain experience in the latest technology.)
  
  
• It must work easily with Oracle and with Oracle’s procedural language PL/SQL.
  
  
• It must work easily in a UNIX/AIX environment.
  
  
• It must be able to coexist with legacy applications.
  
  
• It must be able to deliver output to a web browser. Not only is this the overwhelming trend of current technology; it’s the direction that makes the most sense at Penn, given our multi-platform, multi-OS, multi-database, multi-browser user environment.
  
  
• It should position us to take advantage of the emerging web services architecture if necessary. (The Gartner Group has identified web services as the successor to EDI. It provides a flexible, component-based approach to business-to-business communication.)
  
  
• It should provide support for XML, which has become the lingua franca for data interchange.
  
  
• We should give greater consideration to tools that are based on open standards and are supported by multiple vendors. Single-vendor strategies leave us vulnerable to that vendor’s own agenda.
  
  
• It should allow an easy separation of presentation from processing logic. Put another way, the generation of HTML should be separated from the database interface; it should be possible to implement a completely different HTML front-end without affecting the underlying database activity.
  
  
• The tool should encourage and support the rapid development of applications by allowing for the creation of modular, reusable components.
  
  
• It should encourage portability: we should be able to move it to a different platform and run it with as few changes as possible.
  
  
• It should encourage scalability: we should be able to move from a small pilot venture to campus-wide distribution without rewriting the application.
  
  
• Given that our current expertise in this technology is limited, and that we have a significant number of people who will need training, it should have a manageable learning curve.
  
  

Making the choice

At present there are two viable alternatives for an architectural framework that meet the criteria outlined above: J2EE from Sun Microsystems and .NET from Microsoft. They are often portrayed as being in opposition, but the choice is not necessarily either/or. In fact, the likelihood is that, because of the requirements of different vendor packages, we will need to support both. The question is rather which one should become the standard for applications that are developed in-house.

Both frameworks meet most of the criteria. Both provide the necessary components and services for developing Web-based enterprise applications. Both are modular and scalable and provide support for XML and web services. Both provide access to a wide variety of database management systems. Both are backed by strong vendor support and third-party offerings. (On the down side, both have a steep learning curve and will require a significant investment in training.)

For several reasons, however, we believe that J2EE offers decisive advantages in our current environment.

• We already have a working Java enterprise application (BEN Deposits) and the in-house expertise that goes with it.
  
  
• Most of our servers are UNIX/AIX. Microsoft’s framework is intended to run on Windows-based servers.
  
  
• IBM and Oracle, two key vendors for us, are strong supporters of J2EE and have integrated J2EE support into their products.
  
  
• PL/SQL Server Pages provide a conceptual bridge between current technologies and the J2EE framework, easing the immediate training requirement.

Recommendations

Our overall recommendation consists of two approaches.

For enterprise applications, we recommend moving toward a full-scale J2EE architecture, using a Servlet/JSP approach. We recommend using the architecture developed for BenDeposits as a model for future development.

For smaller applications, where data resides exclusively in Oracle databases on a single platform, we recommend adopting the PL/SQL Server Pages approach. The single-vendor disadvantage in this case is outweighed by the ability to use our existing expertise. It would reduce the immediate training requirement and allow staff to make the transition to a different architectural model, while still using a familiar set of tools.

A final recommendation concerns middleware. Messaging is at the heart of this new architecture. Effective middleware would make it possible to incorporate established mainframe applications into this environment — further separating the specific form of data from the other layers of the architecture. We recommend an investigation of current middleware offerings, with an intent to purchase and integrate one of them into this proposed architecture.

Making the transition

Making the transition to this new architecture will not happen overnight. We recognize that, among other things, this approach will require a significant commitment in training costs, both on the part of management and on the part of individual programmers. We are moving toward an object-oriented, web-based environment that is conceptually foreign to many of our existing staff. We do not feel, in today’s environment — technical, marketing, and political — that we have a viable alternative.

We recommend the following steps:

• Publish the rationale for the change (using something like this document) and invite discussion.
  
  
• Launch a project to evaluate and recommend new application development tools and middleware consistent with the J2EE framework.
  
  
• Choose additional projects, large enough to warrant the architecture but not so large as to overwhelm the team with cross-center support issues, as candidates for the new approach.
  
  
• Schedule training for the staff committed to those projects.
  
  
• As experience is gained with the technology, refine the application guidelines derived from BenDeposits until it’s clear that it’s flexible enough to handle most situations.
  
  
• For staff familiar with PL/SQL but not familiar with the new object-oriented model, provide opportunities to work on moving OWA-based applications to a PSP architecture (or, at a minimum, an IAS environment).
  
  
• Do not attempt a mass conversion of existing applications. The goal is peaceful co-existence and a measured pace of migration to the new environment.

Appendix: Evaluation of existing approaches

Almost by definition, the Oracle-related tools meet three of the criteria

• support for Oracle and PL/SQL
• modularization of code (through PL/SQL packages)
• considerable expertise already exists within AIT

All possess one significant disadvantage as well:

• They’re a single-vendor solution, and Oracle does not have a good track record for ongoing support of its Web-based and client-server products.

Forms and Reports

Pros:

• considerable expertise already exists within AIT

Cons:

• requires that runtime software be installed on each workstation, creating major maintenance and distribution problems
• no built-in support for Web services architecture
• new Oracle releases may require the rewriting of reports

Recommendation:

• Consider this a legacy tool; do not use it for new applications.

WebDB

Pros:

• provides ability for non-AIT staff to generate simple reports quickly, with common interface and menu and options

Cons:

• requires specific server environment (Oracle IAS and Windows NT)
• no built-in support for Web services
• handles only simple reports (single SQL queries), allows virtually no updating

Recommendation:

• Follow through on current plans to upgrade from WebDB to Portal, and use it where appropriate for simple Web reporting applications. (Portal is a significantly different product, and its architecture may reduce or eliminate some of the disadvantages listed above (for example, the need for multiple server platforms). It is unlikely, however, that Portal will become a full-fledged application tool.)

Web Agent

Oracle Web Agent is included here, even though it is no longer a supported product, because we already have several applications that run in this environment. Examples include Position Inventory and the graduate school ExpressApp (although ExpressApp is being rewritten to run on Oracle’s IAS server with the PL/SQL toolkit). Oracle Web Agent is no longer supported by Oracle. Among the other disadvantages:

• presentation logic is embedded in the same PL/SQL code that handles database functions
• no support for Web services architecture

Recommendation:

• Consider this a legacy tool; do not use it for new applications. Consider rewriting existing applications using PL/SQL Server Pages, or (at a minimum) the IAS server environment.

PL/SQL Server Pages

Pros:

• capitalizes on existing expertise in AIT
• allows for modular structure
• allows separation of presentation and logic
• architecture would be compatible with approaches that are more Web Services-oriented, providing a possible upgrade path

Cons:

• single-vendor solution

Recommendation:

• Consider PSP as the best available replacement for existing PL/SQL-based web applications, and for "quick-hit" applications.

We have one application (GRAM) that was written in the PHP environment, and another one — the Student Portal — that is currently in development. PHP is an open-source product, supported by a large and active community; it is one of the most widely-used web application environments in the world. The syntax is fairly simple, there is built-in support for Oracle, and it is tightly integrated with HTML. PHP applications running on the Apache webserver perform well in stress tests; they are highly portable and are likely to be highly scalable as well.

There are significant disadvantages, however.

• While Web presentation can separate from application code, this separation is not encouraged by the structure of the language, and the temptation is to merge the two.
• Modular code is also supported but not encouraged. PHP code can quickly become sprawling and difficult to maintain.
• There is no built-in support for Web Services architecture or XML.

Recommendation:

• Use PHP for small, single-server applications where there are severe budget constraints and a requirement for very fast turnaround