eight integration projects and began work on three, with primary focus on the summer school project. FCPS was in the process of replacing this outdated application based on the old HP 3000.
FCPS uses the summer school application to register students, collect fees, develop schedules, take attendance and assign grades. It was a good focus for integration since it interfaces with the student information, library, transportation, food services and special education applications.
One application requirement was for a clerk registering a student to enter the student name or student ID. At this point, the registration screen would be pre-populated with the student's demographic information, which resides on the student information application.
FCPS was implementing the summer school application in PowerBuilder and Oracle. To meet the integration requirements, IWG needed to determine how the PowerBuilder application would invoke the services available via webMethods. IWG wanted to standardize on Web services, however, FCPS was using an older version of PowerBuilder that did not understand Web services. Other choices include COM, Java and C++ for the interface development.
To use Web services, IWG had PowerBuilder developers invoke Java-stored procedures in Oracle, which in turn invoked the Web services. The integration developers created the Java stored procedure by creating the service in webMethods, then used webMethods to generate the Web Services Description Language (WSDL) file. They used Oracle JDeveloper to import the WSDL file and build the Java-stored procedure that invoked the Web service.
Birth of a New Architecture
The request-and-reply form of messaging is appropriate for synchronous communications and lends itself very well to Web services. The IWG also made use of the publish-and-subscribe form of messaging, which for example, triggers an update to the Student Information Buffer when a student's data is changed.
This buffer maintains a current snapshot of student data. The webMethods platform detects changes to the buffer and publishes the data, which is available to any application that subscribes to the corresponding message. Not only does this allow the summer school application to be informed of data changes, but any application that subscribes, such as special education, could be updated as well.
Will It Perform?
With functional and system testing complete, IWG knew the architecture functioned as designed. Whether it would scale to the load that FCPS required, however, remained to be seen. To avoid any surprises in production, IWG conducted load testing, whose environment used Mercury Interactive LoadRunner. The environment was designed to simulate registrations on the summer school application, which would invoke the Java-stored procedures, and thus execute the Web services on the webMethods platform.
In an attempt to find the breaking point in the architecture, the test increased the load incrementally until the load was more than 100 times the anticipated production load.
Results show that the webMethods CPU utilization increased from a 25 percent average utilization to a 55 percent average utilization -- very good given the high load. The results also show that the summer school server reached its capacity when the script reached the peak load.
With good test results, the IWG and summer school teams moved forward with the deployment of the new integration architecture and summer school application. During the registration period, FCPS enrolled over 26,800 students -- more students than most public school systems enroll during the regular school year.
An Unexpected Benefit
During registration, the summer school team realized it did not have an effective means for informing regular school principals which students actually registered for summer school. This is critical due to the short time between when standardized test results are released and the start of summer school. Principals must ensure that students in need get necessary remediation from summer school.
The summer school application was deployed