Admission and aid @ princeton
1 / 40

Admission and Aid @ Princeton - PowerPoint PPT Presentation

  • Updated On :
  • Presentation posted in: General

Admission and Aid @ Princeton. Tim Hogan Background. First EJB project in ’98 – ’99 Learning experience 3 Users Proved that a Servlet/EJB/RDBMS application can be built and works Did not address performance or availability issues Non-mission critical application

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

Download Presentation

Admission and Aid @ Princeton

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

Admission and Aid @ Princeton

Tim Hogan

Admission and Aid @ Princeton


  • First EJB project in ’98 – ’99

    • Learning experience

    • 3 Users

    • Proved that a Servlet/EJB/RDBMS application can be built and works

    • Did not address performance or availability issues

    • Non-mission critical application

  • Several Servlet (then JSP) applications followed.

    • Reached a bigger audience

    • Increased number of skilled developers

    • Increased understanding of performance and availability issues

    • App Servers improved / Specs evolved

    • Still not mission critical

Admission and Aid @ Princeton

Background (cont.)

  • Time Collection project

    • On-line time cards for 3500 hourly employees

    • Full calculation of wages including overtime and job differentials

    • Mission critical – 22x7

    • Internal to Princeton

  • NOW – Admission and Financial Aid

    • Allow all applicants to apply on-line

      • Admission – part 1 only

      • Financial Aid

    • Current students can apply for aid on-line

    • Back office processes too

    • Mission critical

    • Internal and External to Princeton

    • 24x7

Admission and Aid @ Princeton

Business Scope

  • For all applicants:

    • Provide a registration and log in mechanism

    • Allow applicants to save their applications and come back later to submit

    • Provide customized forms depending on applicant’s status

      • U.S., Canadian, International

      • 2-parent household, divorced, independent students

    • Provide on-demand validation

  • For current students – Financial Aid only:

    • Same as above but no registration needed

    • Can apply for current or upcoming academic year

Admission and Aid @ Princeton

Business Scope (cont)

  • Back office processes – Admissions

    • Print out applications

    • Search facilities

  • Back office processes – Financial Aid

    • Support “Need Analysis” – figuring out how much aid you can get. 3 separate methods:

      • Princeton method

      • Federal method

      • Non-custodial method

    • Each method is a series of formulas and sub-formulas that can be “tweaked” along the way. Also, formulas differ by academic year

    • Support “Packaging” – figuring out what combination of scholarships, grants, jobs to give to a student

Admission and Aid @ Princeton

Business Scope (cont.)

  • Financial Aid processes (cont.)

    • Scholarship allocation – after packaging is complete, auto-allocate scholarships in the most efficient way.

      • Allocate non-Princeton scholarships first

      • Some scholarships are very specific (e.g., Boy Scouts from Kentucky)

Admission and Aid @ Princeton

Technical Architecture

  • N-tier

    • Client - Ns 4.7+ or IE 4.0+

      • IE 5.5+ only for back office

    • Apache 1.3.26 w/Open SSL on Solaris 2.8

    • WebLogic 6.1 sp1 on Solaris 2.8

    • Oracle 8.1 on Solaris 2.8

  • LDAP for authentication of students and staff

  • Yale CAS authentication for applicants

  • SSL between browser and web server only

  • Automated batch feeds (via maestro)

  • 24x7

Admission and Aid @ Princeton


v 1.3.26

Open SSL

WebLogic 6.1




Oracle 8.x

Technical Architecture


Web Server

App Server

DB Server




Authentication Server

Admission and Aid @ Princeton

Some Stats

  • 22 Entity Beans – all CMP

  • 4 Stateless Session Beans

  • 132 Business/Support classes

  • 10 Servlets

  • 108 JSPs

  • 40 distinct windows

Admission and Aid @ Princeton

Yale’s CAS

  • CAS – Common Authentication Service

  • Allows “single sign-on” between Admission and Fin Aid applications.

    • Cookies must be enabled

    • Provide your own authentication class

    • At entry point of each app you want to involve, add CAS jsp tags to automatically handle single sign-on process.

  • Customized and installed in 2 weeks

    • Mostly learning curve issues

  • CAS architecture

Admission and Aid @ Princeton



Log In and



Fin Aid

Using CAS

2. Apply

3. validate

4. Exit

1. Log In

8. Log Out

5. Apply

6. validate

7. Exit

Admission and Aid @ Princeton

Using CAS – Rules of thumb

  • Each app is a standalone WL instance

  • Each application is responsible for its own session management once a user has entered

  • Each app has only 1 entry point that coordinates with CAS

  • “Exit” invalidates the session for that app and redirects back to CAS

Admission and Aid @ Princeton

Application Design – Rules of Thumb

  • Standard "MVC" design

  • JSPs for painting screens

    • Java script for field validation only

    • Liberal use of java “beans” to minimize java code in JSPs

    • Put all your java code “at the top”

  • Servlets to manage screen flow and coordination between JSPs and session beans

    • Did not use one “controller” servlet that delegates to other servlets

    • Common behavior via subclassing

    • Avoid doGet(), use doPost() instead

  • Stateless session beans as "transaction controllers“

  • Domain objects contain business logic and map directly to an entity EJB

Admission and Aid @ Princeton

Application Design (cont.)

  • Entity beans – CMP only

    • Local interfaces used, not remote interfaces

  • 1 Entity Bean = 1 Table

    • Not “course grained” – but do map to business entities.

  • Entity Bean Guidelines

    • Entity Beans are only directly accessed by other Entity Beans or Session Beans. That is, Servlets/JSPs do NOT access Entity Beans.

    • Entity relationships managed via CMP, NOT managed by Session Beans (as in earlier projects) – big performance improvement.

Admission and Aid @ Princeton

Application Design (Cont.)

  • An entity bean has an associated "domain object" (a regular java class)

    • Can be stored in the HTTP session

    • Can be used by Servlet/JSP/EJBs/etc

  • Entity beans only used where we have objects (tables) that are directly updated during a transaction

Admission and Aid @ Princeton

Application Design (Cont)

  • Static/lookup tables

    • We use one (large) singleton class to access all static tables

    • Lazy initialization

    • Static data queried once and stored internally

  • Implications:

    • Assume data does not change frequently

    • Must restart server to refresh

  • Future enhancement

    • Administrative function to clear out static tables from memory. This will force a reload

Admission and Aid @ Princeton

Application Design (cont.)

  • 600+ unique data items, each is uniquely named and is consistent across:

    • txtStuFirstName (HTML)

    • stuFirstName, getStuFirstName(), setStuFirstName() (java/EJB)

    • STU_FIRST_NAME (database)

  • Heavy use of reflection to move data items between HTML -> Java domain objects -> EJB -> Database

    • Very easy to add data items later

    • Very little coding (reflection takes care of it)

  • Standardized 100+ abbreviations

Admission and Aid @ Princeton

Technical Issues

  • Performance

  • Should we cluster?

  • Development environment

  • Why use EJB

Admission and Aid @ Princeton


  • On-line applications had to be as fast as possible

    • Each movement between pages posted all data from that page and it had to be cached

    • “Saving” the application had to be fast

    • Saving data to 9 different tables

  • Original implementation used BMP where bean relationships were managed by Session Bean

    • 3 - 5 seconds to save

  • Moved to CMP (which handled all relationships too)

    • 0.5 seconds to save

Admission and Aid @ Princeton

Performance (cont.)

  • Volume Testing – Financial Aid

  • We knew our peak times and volumes based on previous years paper applications

    • Early Decision (Nov 1) – 2000 applications

    • Regular Decision (Feb 1) – 5000 applications

  • Assume 50% are submitted during the last 3 days.

  • Performance Goal – support 9000 applications over the course of 3 days

    • 3K/day – during 8 hour period (8pm – 4am)…378 apps/hr

Admission and Aid @ Princeton

Performance (cont.)

  • Load Runner – Mercury Interactive

  • Simulated 100 simultaneous users submitting 5 applications in 30 minutes

    • 2 sec avg response time

  • Maxed out the testing machine first

  • 1000 apps/hr seems good enough for us

Admission and Aid @ Princeton

Performance (cont.)

  • 200 meg ram allocated to app server

  • JRE 1.3.1 Hotspot – Server mode

  • Hardware Sizing

    • Estimate transaction volume at peak and non-peak times.

    • Advice from BEA Consultant

      • Memory is most important

      • Many smaller servers is better than one large one

      • Recommended clustering

    • Choose server type (small/medium/large)

    • Chose ES250 - Dual 300Mhz, 2 Gig ram

      • Allows for more CPUs

      • Max out memory

  • Put all static content on Apache so app server is not burdened with it

    • *.gif, *.css, *.js

  • Cache all static data in a singleton

Admission and Aid @ Princeton


  • Like our other applications, we did not use clustering

    • Expensive licensing (20K / cpu)

    • Generally, overkill for our application

    • 24x7 = keep it up most of the time

  • However, we now have 7 WebLogic applications all running on the same app server

    • Each runs its own WL instance

  • If this machine crashes, we’re in big trouble

  • We are considering clustering in the context of general availability of ALL WL applications

    • Gives us a redundant app server

  • Recently, a DB server that supports 20+ apps died

Admission and Aid @ Princeton

Development Environment

  • Developers can choose any IDE they want

  • 2 used WebGain and WL on W2K desktop

  • 1 used VisualAge on W2K and ran WL on Solaris

    • Used SMB to map Unix directory to Windows drive

  • PVCS for source control

  • Note: our code is compiled in VA on W2K, and runs on Solaris 2.8 – no problem

Admission and Aid @ Princeton

Development Environment

  • We have 4 environments

    • DEV, QA, PROD are all exactly the same

      • Solaris 2.8 with same patch level

      • Same exact directory structure

      • Same exact WL version and patches

      • Same exact Apache

    • Developers can opt to have their own “local” environment

      • On their W2K desktop or unique Unix directory (pre-dev)

    • This makes migration very easy

  • We DON’T deploy as WAR file

    • Not practical when you only need to change 1 JSP

Admission and Aid @ Princeton

Why use EJB?

  • Technically, we don’t need EJB in our apps because

    • Transactions don’t span multiple sources

    • Our services don’t need to be remotable (location independent, distributed)

  • However, we use EJB because:

    • It’s very very fast

    • Auto commit and rollback (very convenient)

    • Built-in relationship management with the 2.0 spec

    • We don’t have to write SQL (very lazy)

  • One EJB “bug”

    • Transactions spanning multiple tables are not always updated in the correct order (we had to disable constraints to get around this)

Admission and Aid @ Princeton

Monitoring Availability

  • Tivoli – every 5 minutes

    • Checks for a static page on Apache – is Apache OK?

    • Logs in – is CAS OK?

    • Goes to the “Welcome” page – is the App Server OK?

    • Logs out

  • If one of these fails, we get a page

Admission and Aid @ Princeton

Usage Stats

  • 98% of our users are IE 5.0 or higher

    • Most are IE 5.5 or 6.0

    • This includes most AOL users

  • 1% AOL browser

  • 1% Netscape (usually on MAC)

  • Average session time is 40 minutes

  • Usually 2 or 3 visits

    • Check it all out (5 minutes)

    • Fill it our for real (40 minutes)

  • Of the 3000 Fin Aid applications:

    • About 15 had cookies disabled

    • No one had java script disabled

Admission and Aid @ Princeton

Usage Stats (cont.)

  • Peak times – 8:00pm – Midnight

    • Moves across time zones

    • A lag over the Pacific, then starts up again in China

  • # Fin Aid applications

    • 2132 - USA

    • 622 – Canada

    • 220 – India

    • 180 – China

  • Over 35 countries represented

  • 2/3 are students, 1/3 parents

Admission and Aid @ Princeton

The End

Thank You

Tim Hogan

Admission and Aid @ Princeton

Design Challenge #1

  • Calculations and formulas change from year to year

  • System must handle multiple versions of formulas simultaneously

  • Formulas are defined in Reverse Polish Notation

  • Formulas are based on labels

    • M_AGI = 67800


    • Therefore, every data item is a String in the database because it can be an actual number or a formula

  • Formulas are then associated with a particular “need method” and academic year

  • We can make all calculations table based which can be modified by user

Admission and Aid @ Princeton

Design Challenge #2

  • On-screen validation must be flexible

  • Used a table-based approach – a validation engine

  • Validation Table defines

    • Screen name

    • Java object involved

    • Field name

    • Validation criteria

      • Field format / required / relationship to other fields / method name [for special validation]

  • Heavy use of reflection

  • Validation logic is a simple table change

Admission and Aid @ Princeton

Issue - Performance (Specs)

  • Goals

    • Support 100 simultaneous users with 3 sec response time

    • Run payroll calculations in allotted time window (2 hours)

    • Size hardware as best as possible and allow room to grow

Admission and Aid @ Princeton

Issue - Performance (Approaches)

  • Use App Server (EJB) for web transactions only.

  • Run mass updates in "batch" mode while App Server is down.

  • Only App Server can update database while it is up.

  • Cache everything:

    • Entity beans

    • Lookup tables / Rule tables (Singletons)

    • DB Connections

  • Static content on Web Server, not App Server

  • Split large batch jobs into smaller ones running in parallel.

  • Minimize/eliminate external DB calls. Duplicate data instead.

Admission and Aid @ Princeton

Issue - Performance (Tuning)

  • Used tool WebLoad by RadView Software

  • Each “user transaction” added 30 time entries then removed them all (many servlet / EJB hits and db IO)

  • Did not simulate “think time”

  • Started with 50 users and increased by 25 until 3-sec response time was reached at 150 users.

Admission and Aid @ Princeton

Issue - Monitor Availability

  • WebLogic provides a “ping” utility

    • Via maestro (scheduling software), ping the server every 5 minutes.

    • If ping fails 3 times, assume the server is locked up or dead.

      • Recycle server

      • Send out beeper and e-mail

  • During high volume periods, ping fails even though server is ok.

    • We automatically recycled the server during a very heavy period!

  • Now, we also check if Unix process is alive

    • kill –0 pid

Admission and Aid @ Princeton

Non-Standard Ports

  • To support multiple WL apps on one machine, each runs off a different Unix port

  • We define an Apache virtual host that maps to that WL instance

    • We must define a separate VH for each WL instance because the WebLogic/Apache proxy bridge requires it

Admission and Aid @ Princeton






Log In and



Fin Aid

Non-Standard Ports

3 URLs:

Admission and Aid @ Princeton

Non-Standard Ports

  • However, some ISPs do not allow HTTP or HTTPS access via non-standards port (any port not 80 or 443)

  • We’ve moving to a named-based virtual host approach (vs the port-based virtual host approach)

  • This means we have many more certificates to manage too

Admission and Aid @ Princeton



Log In and



Fin Aid

Non-Standard Ports (cont.)

3 URLs:

Admission and Aid @ Princeton

  • Login