Admission and Aid @
Princeton
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
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
Technical Architecture
encrypted
Web Server App Server DB Server
Authentication Server
Client
TrustedSub-Net
Apachev 1.3.26Open SSL
WebLogic 6.1
NS LDAP
DatabaseOracle 8.x
Browser
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
Using CAS
Log In andRegistration(CAS)
Admission
Fin Aid
Browser1. Log In
2. Apply
3. validate
4. Exit
5. Apply
6. validate7. Exit
8. Log Out
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
Performance
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
Clustering
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
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 ADJ_AGI = M_AGI + F_AGI – F_MEDEXP 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
Non-Standard Ports
Log In andRegistration(CAS)
Admission
Fin Aid
Apacheapps.princeton.edu
7000
8000
9000
3 URLs:https://apps.princeton.edu:7000/https://apps.princeton.edu:8000/https://apps.princeton.edu:9000/
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
Non-Standard Ports (cont.)
Log In andRegistration(CAS)
Admission
Fin Aid
Apacheapps.princeton.edu
admit.princeton.edu
3 URLs:https://admit.princeton.edu/https://cas.princeton.edu/https://finaid.princeton.edu/
cas.princeton.edu
finaid.princeton.edu
Top Related