Application Servers at Ohio’s DOT
Using application servers to manage the middle tier between client/server and mainframe machines often begins as a do-it-yourself project. Most IT managers quickly realize technical issues demand the expertise of an application server guru or two.
This was the case at the Ohio Department of Transportation. The state agency, propelled by a desire to make key applications Y2K-compliant, began a code rewrite. Managers realized -- for efficiency and ease of modification -- the business rules governing the programs should reside in an encapsulated middle tier.
"We saw a need to not only encapsulate the business rules, make them easy to modify and put them on a middle tier so many people can hit them, but we were also looking for a mechanism to pool database connections" and to potentially begin sharing objects among many systems, explains Angelo Serra, director of information technology at the department.
The first program to be revised was a request for leave application that employees use to request -- and managers use to grant or deny -- leaves of absence. Part of an umbrella payroll and leave system, the request for leave program changes every three years with the terms of each new labor contract.
An Internet-based hauling permits program, which enables truckers to request permits to travel the state’s roads, was next in line, followed by programs that facilitate internal accounting procedures.
Late last summer, bureau representatives sat down with a team of Windows NT-skilled developers and listed the department’s requirements. A smaller group was tasked with pinpointing vendors that could meet the requirements. Three vendors made the list: Inprise Corp. (www.inprise.com), BEA Systems Inc. (www.beasys.com) and GemStone Systems Inc. (www.gemstone.com).
"We quickly noticed that application servers fall into two camps," Serra says. "They either were very good with applications that are Web-based or very good with applications that are traditional application-based. Inprise was the first company we saw that was merging the two worlds and [making it] relatively easy to get the information to both worlds. It fit in with what we were looking for," he says.
Based on an Inprise application server, the new Request for Leave Checker program notifies managers when they have leave requests to review. Inprise’s Application Center monitors the program, watching how many connections are "hitting" the object.
If the number of users exceeds a threshold, the application server fires up a second object so performance is maintained. If one or both objects fail, or performance deteriorates, Application Center pages or e-mails the IT staff.
The altered system shaved 30 minutes a day from the schedules of the developers, time formerly spent checking the request for leave program and correcting errors or system problems. Although the upgrade has a return-on-investment benefit, Serra says the more important benefit is the peace of mind it brings to developers. "They know that -- unless they get a page -- everything is running. And if something goes down, the product will take care of it," he says.
The developers initially struggled with technical issues, such as how the agents worked, how CORBA worked over subnets and how the ports hooked up. To help overcome the learning curve, the department hired two consultants to act as mentors to the developers. The consultants were not allowed to explicitly create solutions for the developers, and they were prohibited from writing code. It turned out to be an effective method of transferring knowledge, Serra says.
The request for leave project was so successful that eight more application server-based projects are planned, Serra adds. All are expected to be deployed this month, one year after the team began investigating application server technology.
"RFL Check has not failed once," Serra says. "It’s pretty much running itself. We’ve been very happy with that."