University of Pennsylvania
Core Administrative Systems
Architecture Recommendations

FAST: the Framework for Administrative Systems Technology

Latest Update: 21-May-2004

(New items in blue)

 

 

 

Welcome to the "status page" for the Core Administrative Systems Architecture team. As you've probably heard, ISC is in the process of revising the architecture guidelines for web-based core administrative systems. ISC has been developing web-based applications since 1994. A recent explosion of technology in this area has made it essential to focus our efforts and choose a path that will allow us to take advantage of the best of the emerging approaches.

Bookmark this page and visit it often for the latest updates on where we are, what decisions have been made, and what to look for in the near future.

Click on one of the items to the left to view the status of that item.

If you have any questions or comments, please contact Tad Davis at davist@isc.upenn.edu.

8-May-2003. A quick recap of project objectives:

  • A robust development environment that facilitates the development and maintenance of high-quality administrative applications.
  • Support for multiple developers on a given project.
  • Support for multiple simultaneous project teams.
  • Applications that are not tied too closely to a specific J2EE application server.
  • Web page (JSP) development should utilize a visual tool.
  • Ability to leverage the existing skill set of the technical staff.
  • Support for code reuse.
Members of the Team

Current members of the Architecture Team are as follows:

AIT
Jim Choate (team leader)
Stuart Benoff
Nanda Bhaumik
Tad Davis
Chris Hyzer
Bill Kasenchar
Michael Levin
Artur Matraszek
Ed Read
Elaine Rymsza
Ben Shniper
SEO
Bill Ramirez
Dan Sheehan
Network Engineering
Mark Sirota
Java Framework

21-May-2004. Version 1.0 of the framework is nearing completion. (Some applications using an earlier version of the framework are already running in production.) In MVC terms, Java provides the Controller portion of the architecture, using XML configuration files to determine what to do next. JSP pages -- HTML with embedded "custom tags" -- provide the View (the "presentation" of the data to the user). PL/SQL packages provide the Model (the business logic for the application). A simple example would proceed as follows:

  • The user fills in a request and clicks the "Show Data" button.
  • Java, using its XML navigation files, decides which PL/SQL package to call.
  • The PL/SQL package reads the database and places the data in a PL/SQL object.
  • Jave "marshalls" the data into a Java object and decides which JSP to send it to.
  • The JSP -- HTML and custom tags ("<fast:assignment>") translated into a Java servlet -- formats the data for the browser.
  • The user updates the data and clicks the "Submit Changes" button.
  • Java marshalls the data back into a PL/SQL object and sends it to the PL/SQL package indicated by its XML files.
  • Oracle processes the update and sends a response.

The flexibility promised by the MVC architecture has become a reality: it is possible to change the business logic without modifying the presentation; it is possible to change the navigation without modifying the business logic. Chris Hyzer and his intrepid band of programmers have provided a rich set of tools, tags, and libraries that tie it all together. We are now exploring an expansion of the Model portion of the architecture that will allow database logic to be embedded in Java as well as in PL/SQL.

10-July-2003. The framework now includes an automated process for loading and unloading HTML form variables. (Form variables need to be translated into Java objects before they can be processed.) A process to synchronize Java and Oracle objects is in development.

12-June-2003. Our framework has a name, thanks to Chris Hyzer: FAST -- the Framework for Administrative Systems Technology.

30-May-2003. It's been noted that the explanation of MVC cited in an earlier note -- on 20-March-2003 -- wasn't as clear as it could have been. Model / View / Controller is a particular approach to designing interactive applications. The Model essentially comprises the objects and business rules that are represented by the application -- what most people consider the "guts" of the application; the View is a particular way of looking at those objects and rules; and the Controller is the software that navigates the other two. If the code for Model and View are kept apart, it's easier to design a new View when a new device comes along (for example, a handheld computer or a speech-recognition system); the behavior of the Model doesn't change. Other places where you can learn more about this approach include the software company Object Arts, a Java Resources site at Oberlin College, and a web site maintained by Cristobal Baray, a graduate student at Indiana University.

15-May-2003. In order to get the maximum benefit of the web environment, we are leaning strongly toward requiring that JavaScript be enabled in browsers for our applications. The design options would be vastly increased by doing so. At one point, because of concerns about security and incompatible implementations, the use of JavaScript was discouraged. Since then, however, standards for scripting have been developed by groups like the European Computer Manufacturers Association (ECMA International) and the World Wide Web Consortium (W3C), and JavaScript has become ubiquitous on the web. In addition, we already have web applications at Penn, like BenReports, that require JavaScript to make use of all features of the application.

8-May-2003. Our goals include these specific enhancements to our existing framework:

  • Replacing our home-grown "HTMLController" module with a custom tag library.
  • Automating the process of loading and unloading form variables. (This will be similar to the process used by Struts, but it will use tools we already have in-house.)
  • Resolving synchronization issues between Java and Oracle objects.
  • Examining the feasibility of a common action servlet.

20-March-2003. After consultation with LearnQuest, we've decided that Struts will not play a role in our application framework.

There are many similarities between Struts and the architecture we've already worked out. Conceptually, both are MVC frameworks (Model-View-Controller). The MVC paradigm separates the Model of the external world (the application) from the View (the "presentation" of the data to the user, for example through a Web browser) and the Controller (the traffic cop for user input). You can find a fuller explanation of MVC at various Web sites, like the Object Orientation Tips site maintained by Yonat Sharon.

The features of Struts that we don't have equivalents for -- like the automatic generation of routine coding to load and unload fields -- can be reproduced in-house without the complexity that integrating Struts would create.

We are, however, continuing to look at ways that we can streamline our framework. For example, custom tags may be able to replace some of the special HTML-generation routines we've developed. (Custom tags generate HTML in a program-like fashion; but they make it possible to view the rendered page in a visual environment like DreamWeaver MX.) In addition, the Oracle utility JPublisher simplifies the process of translating Java objects into Oracle objects.

30-January-2003. In addition to conducting training classes, LearnQuest will be working with us as a mentor on the Java framework and on the possible use of Struts. (Struts is "an open source framework for building web applications," according to the official web site. One of the options we're considering is using some of the components of Struts in our architecture.) This mentoring will include a review of what we've already done in BenDeposits. The deadline for recommendations on the Java framework has been moved to the end of March.

17-January-2003. The move toward Java will not require a wholesale change in the internal architecture of our database systems. Database work will continue to be done in Natural and PL/SQL. Our architecture will use Java — Java Server Pages in particular — as a front end. Natural and PL/SQL subprograms will be called as needed to process the data.

The architecture guidelines do not, as yet, address the "look and feel" of applications. New systems that are currently in development — for example, the new Student Loan system — will make use of this new architecture. "Look and feel" issues will be worked out during that process and will be standardized when we have the benefit of that experience.

19-December-2002. As you can see from the recommendations document, we are moving toward a Java-based architecture for new core administrative systems. There are a variety of ways this architecture can be implemented. Our approach will emphasize embedding business rules in Natural and PL/SQL software wherever possible. Michael Levin is investigating the options and should have recommendations for the team by the end of January, 2003.

Infrastructure

21-May-2004. Having established a robust framework for software, we have turned our attention to the issue of hardware infrastructure. Tests were conducted on different server configurations, and the results have led to a new recommendation: that we adopt an LVS (Linux Virtual Server) approach. In LVS, two Linux servers act as routers (one active, one backup), and additional servers provide the transactional and load balancing power. Each server has a full copy of the application. The router decides which server to send the request to depending on demand and availability. (It's called a "virtual server" because to the outside world it looks like a single server.) The capacity of the LVS can be expanded incrementally by simply adding additional servers. LVS includes a robust failover mechanism, which ensures that the system remains "up" even when one or more of the servers are down. Tests indicated that with off-the-shelf hardware running LVS, we could achieve 3 to 4 times the throughput with a 20% cost savings over our current approach (using RISC processors and proprietary software).

20-March-2003. Eclipse and WebSphere are now working together.

21-February-2003. The WebSphere upgrade is turning out to be more challenging than expected. The differences between v3.5 (which we are currently using) and v5.0 are considerable. The BenDeposits application has been tested in this new environment, but we have not yet hooked up Eclipse -- our preferred development environment -- to WebSphere to allow further development. Upgrades are scheduled for completion in early March.

30-January-2003. The effort to upgrade WebSphere and Java continues. (WebSphere, an IBM product, is the web application server that runs BenDeposits. We have not yet made a decision about which web application server will be part of the final recommendations. Another contender is Oracle's 9i Application Server (Oracle9iAS). Both are compatible with the J2EE approach.)

17-January-2003. We are upgrading WebSphere and Java for compatibility with the latest generation of tools.

Tools and Development Environment

21-May-2004. The development environment has taken shape much as it was described earlier. Most of the components are open source. Eclipse provides the basic environment -- the "hub" into which all the other components tie. Software management is provided by CVS. Java coding and most of the interaction with CVS occur within Eclipse. From within Eclipse, files can also be opened with Excel (to do the object and navigation design) and DreamWeaver (to do the HTML development). Macros translate the Excel worksheet designs into XML files. Apache Ant compiles the resulting applications. Most of the database work is done within Toad, an Oracle development tool; where necessary, scripts are copied and pasted from Eclipse into a Toad window and executed from there. The Java code resides in the FAST components, and developers rarely have a need to extend it: most of the development work is done in Excel, DreamWeaver (using custom tags), and PL/SQL.

10-July-2003. We've installed Apache Ant, a Java-based build tool, as part of the development environment. ("Ant" is supposedly an acronym for "Another Neat Tool." Build tools are roughly equivalent to compilers.) In addition, a method has been developed to automate unit-testing as part of a build.

12-June-2003. Great progress has been made on the effort to develop custom tags that can be used within DreamWeaverMX. The tags provide a way to invoke "building blocks" of Java code within an HTML page, while hiding the complexity of what's actually occurring behind the scenes. By adding a few strategically-designed tags to a page, the web designer is, in effect, assembling the application itself. In addition, a standard approach to navigation has been developed, and the process of validating pages against XHTML standards has been automated.

30-May-2003. An SSL certificate has been installed on the development server, so the Mac version of Internet Explorer will now work with this server in SSL mode. The Advanced Technologies team is working with ISC Communications to develop Javascript routines, custom tags, and HTML standards for use with DreamWeaverMX. XHTML is also being investigated as an option, although if we chose to go that route, we would not try to retrofit existing applications. (XHTML is a reformulation of HTML4 to conform to XML standards.) We are also exploring the use of Bugzilla as a development tool. Bugzilla is a bug tracking and reporting application originally developed for use with Mozilla, the open-source Web browser that forms the basis of Netscape. While this product was originally considered specifically as a tool for developing web application, it may be useful in other development efforts as well.

15-May-2003. One specific problem affecting Macintoshes in the development environment is Internet Explorer's certificate limitation. The Mac version of this browser has no option for adding certificates from sites other than those in an approved list. Many of our certificates are self-generated, and Internet Explorer on the Mac will not work with them. One option for getting around the problem is to buy a certificate for the development platform from one of IE's approved vendors.

8-May-2003. Target date for implementation of the development environment has been moved to early Fall. Meanwhile progress is being made. We've worked out the process of incorporating DreamWeaver running on a Macintosh into the development environment, which gives us greater flexibility in working with web developers. We will be using JSP custom tag libraries within DreamWeaver, which will allow web developers to work with a more complete model of the web page. We are also near the point of being able to test Samba, which will integrate the development environment's file system with our Windows-based LAN.

20-March-2003. Our recommendations for the development environment are as follows. On the desktop:

  • Eclipse, with the WebSphere and UML plugins
  • TOAD, which provides a PL/SQL development environment (and which is already heavily used within AIT)
  • DreamWeaver MX
  • a Web browser

On the Web / application server:

  • Samba, the Unix-to-Windows file system mapping utility

Here's a diagram:

These tools will be in place by June 1st. (See the comments under Training for more information about UML.)

21-February-2003. The target date for final recommendations on tools and environment has been moved to mid-March. The target date for implementation of the development environment is the beginning of June.

30-January-2003. Our suggested approach to tools has changed slightly. Originally we were planning to use a Windows 2000 platform as our development server. The disadvantage is that the test environment would differ substantially from the production environment. The open source product Samba would address that problem, and we are going to evaluate it as part of our overall effort. Samba would allow us to keep the source code on our AIX platforms and compile the code directly to the application; but it would also allow us to access the source code directly with the Windows-based development tools we already have (or are planning to acquire).

17-January-2003. Eclipse will be our development environment for Java applications. As a development environment, it will be roughly equivalent to ISPF for mainframe applications; it's where the Java coding will take place. Java training will be integrated with Eclipse.

19-December-2002. Just as there are many approaches to designing a web-based environment, there are many application development tools and environments. One environment we're investigating is Eclipse, which was originally developed by IBM, but which is now an "open-source" product. It's designed to provide a framework for other tools, which can be plugged in as needed. Nanda Bhaumik is evaluating tools and environments, and should have recommendations on tools and environments by mid-February.

Middleware

21-May-2004. We've deployed Shadow, from Neon Systems, in our production environment, and it is.currently being used in Ben Deposits. For FAST-based applications, it has been integrated into the framework. Several FAST applications are being developed right now which will use Shadow (Online directory, PennERS, Student Borrowing). All of these applications initiate transactions on the application server (not the mainframe). We do, however, have a proof of concept running where transactions originate on the mainframe (as well as one where they originate in the Oracle database).

10-July-2003. We've signed a contract with Neon Systems to use Shadow as our middleware. Texas A&M also uses Shadow, and we're studying their approach; they've developed a number of useful Java-to-Natural tools using Shadow as a base.

30-May-2003. Shadow, from Neon Systems, has been tested successfully with Penn's implementation of Adabas security. A simple Java application was created as a "proof of concept." The application retrieves a name from an Adabas file (using SoftwareAG's Adabas programming language, Natural), updates it in the Java application, posts the update to Adabas (again using Natural), and then retrieves the name again to verify the update. Shadow is the product that makes it possible to go from Java to Natural and back again. A volume test of this application, involving 20,000 updates, was run on Thursday, 29-May-2003. Licensing negotiations are now in progress.

8-May-2003. We're testing Shadow, from Neon Systems, as a candidate for our Java-to-Natural middleware. There are some configuration issues that have come up, mainly around Penn's implementation of Adabas security. It is clear, however, that a middleware product that provides a Java-to-Natural bridge is an essential component of our proposed architecture.

20-March-2003. The EntireX test was successful, and it appears to be an excellent product, but there's a snag: the price tag. With license fees running well into six figures, the product can't be justified at Penn on the basis of costs and benefits. Fortunately there are other products that provide similar functionality, and we'll begin looking at them. One is Shadow, from Neon Systems. Like EntireX, Shadow allows the integration of Adabas, Natural, and CICS systems (which we have) with Java-based systems running on WebSphere and Oracle 9iAS platforms (which we also have). Although this product may require more low-level coding, licensing may be ymore flexible.

21-February-2003. Testing of EntireX to date has been successful. So far the link from Natural to Java to Oracle has been tested; so has the link from Java to Natural. The full link from Oracle to Java to Natural is still being tested. For the sake of completeness, the test will include COBOL ADASQL, which the product supports, even though we don't have plans currently to use this feature. The target date for installation of middleware is mid-April.

30-January-2003. EntireX has been installed. We are working with Software AG to install and run a benchmark application before we begin our own testing. A key requirement will be the ability to call a Natural program from within an Oracle PL/SQL module. The target date for product selection has been moved to the end of February.

17-January-2003. Software AG made a presentation of their middleware product, EntireX. EntireX provides a way for Java applications to call Natural subprograms. This would expand the range of processing options available to Java applications, and it would open the possibility of generating new web-based front ends for some existing processes. We are in the process of conducting a 90-day trial of the product.

19-December-2002. A key component of the new architecture will be robust and flexible "Middleware." Middleware will provide a bridge between our Java applications and Adabas application data on the mainframe. Elaine Rymsza is heading up the effort to identify the best middleware for our environment, with an emphasis on support for Natural. We are in the middle of vendor demos at the moment. Product selection should occur in late January.

Training

20-March-2003. The team members, along with other ISC staff, attended a two-day course on OOA in late February. The course was essentially an introduction to UML (Universal Modelling Language). UML comprises a set of diagrams that describe objects, "use cases" (scenarios for user interaction with the system), and other system characteristics. It's clear that not all diagrams are useful for all projects; for our purposes, some would actually add complexity rather than reduce it. The advantage of UML is that it's an industry-wide standard, so it provides a common language for talking about systems with vendors, consultants, and new staff. Guidelines for the use of UML will be developed as part of the Student Loans project.

There are many Web sites that give an overview of UML. The Object Management Group includes a short introduction to what UML is "all about"; the TogetherSoft site includes a brief tutorial on nine of the most common diagrams.

30-January-2003. The first OOA course will be held on February 27th and 28th, in Philadelphia. The overviews -- also conducted by LearnQuest -- will begin soon after. Assuming our experience with the training is successful, all of the training courses and overviews will be repeated. (This is by no means a one-time venture.)

23-January-2003. A correction on the OOA course: it's a 2-day course, not a 3-day course.

Also, some clarifications regarding the courses in general. Staff will be selected for training based on their project assignments. We expect the courses to be offered again in the future. (In the meantime, if you're interested, Bill Clark has multiple copies of the book Object Technology: a Manager's Guide, and you're welcome to borrow a copy.)

Finally, all AIT staff are encouraged to sign up for the overview session when it becomes available.

17-January-2003. LearnQuest will be doing the Java training. There will be three classes: a 3-day class in Object Oriented Analysis and Design; a 5-day class in Java; and a 2-day class in JSP (Java Server Pages) using DreamWeaver MX. The courses will be in Philadelphia, but will not be on site. The OOA/OOD course will begin soon.

In addition, there will be separate in-house overviews for staff who will be involved in these projects but not actually writing code.

19-December-2002. Obviously with all these changes on the horizon, new skills will be required. Jim Choate is putting together a training plan and investigating training vendors. Training will probably begin in March.

Communications

21-February-2003. Communications with the University community about these changes will begin in April.

19-December-2002. This web page, and the architecture document that outlines the proposed architecture, are part of a larger effort to "get the word out" about these changes. Tad Davis is working on the communications, both internal to ISC and with the wider University community. Watch for more public discussion of these changes in February and March.