Mainframes make Web connection
- By Brian Robinson
- Dec 03, 2000
When the Interior Department's mega-business center built its mainframe-based
payroll system, information technology managers had the foresight to know
that, sometime down the road, there was a graphical user interface in the
Indeed, as at many federal agencies, the issue is not how to phase out
mainframes, as some predicted would occur with the rise of the Internet
and distributed computing. Instead, the imperative is how to increase the
mainframe's contribution by leveraging its rock-solid performance in today's
graphically rich, network-based computing environment.
At Interior's National Business Center, the first-generation Federal
Personnel/Payroll System (FPPS) used the character-based screen familiar
to old-school 3270 terminal users, but buried deep inside the logical design
of the program were the hooks for that eventual GUI.
So, for Michael Colburn, then the chief of the National Business Center's
applications planning and technology group, moving to a graphical front
end was not a wrenching thought. What it came down to was the choice of
GUI to use. The problem was that, given his druthers, he probably would
not have chosen a Web browser. But a 1996 departmental bulletin recommending
that browsers be the primary interface for DOI administrative systems decided
the issue for him.
The Web browser policy ruled out the use of traditional GUIs in a Microsoft
Corp. Windows environment.
"My concerns were ones of performance, which is somewhat better for
those traditional GUIs," said Colburn, who was recently appointed assistant
professor of computer information systems at Colorado Christian University's
School of Business. "There are built-in delays when retrieving data using
The choice of which language to use in building the Web environment
was, in the end, not much of a choice at all. HTML was the standard for
building Web pages, but for several reasons it wouldn't meet the needs of
the National Business Center.
With the FPPS hosting a total of about 2,200 screens, Colburn said,
it would have taken far too long to develop that many screens in HTML. Also,
because HTML uses Hypertext Transport Protocol (http) — a "stateless" protocol
that does not keep track of data for the next use — transactional systems
such as the FPPS would require code to be developed to manage user status.
"This is not a trivial undertaking," he said.
In the end, the National Business Center decided to go with Java applets,
even though at the time the decision was made there was also concern over
their performance. Nevertheless, Java had the advantage of being a full-blown
programming language that offered port-ability between operating environments — something a possible alternative such as Microsoft's ActiveX doesn't provide — and a much more sophisticated GUI than HTML.
Also at issue was the need for the FPPS' functionality itself to be
improved. In addition to serving Interior, the FPPS also serves the Education
Department, the Social Security Administration and other smaller federal
agencies, which pay the National Business Center for those services. As
such, the FPPS competes on a corporate model with other systems and needs
constant upgrades to keep up with demands for additional features.
"That means we have to have a way of interfacing FPPS with such things
as [enterprise resource planning] systems and integrating it with various
[commercial off-the-shelf] software," Colburn said. "Because of that, we
also initially looked at ways of rewriting parts of the mainframe code,
to allow for that. But we concluded that would be far too costly."
So the National Business Center decided to work through the interface
code only and leave the legacy code untouched. That in turn meant employing
screen scraping, where software grabs data intended for display in a character-based
mainframe environment then reformats and redisplays it in the Web environment.
It's a common approach in Web-enabling legacy applications and has the advantage
of leaving all of the system business rules untouched on the mainframe.
But it also adds another layer to the interface code, which increases response
That put the onus for performance on the tools that would be used to
build the Web system. The National Business Center, after a review of the
literature, invited a number of vendors to a "fly-off" in which each built
a pilot of the system on-site, with each firm measured against various benchmarks
such as ease of development and the performance of the final product.
The National Business Center chose Jacada for Java, a product of Jacada
Ltd. It employs rules-based technology to generate Java clients in 100 percent
Java source code that are deployed to any desktop running any browser. However,
Colburn warned that Netscape Communications Corp.'s browser's implementation
of the Java Virtual Machine, used to run the Java applets, was inferior
to that of Microsoft's Internet Explorer, at least until the release of
Version 6 of the Netscape browser.
Colburn said the Jacada tools have worked "exceptionally well" in that
they've generated code with very few bugs. Largely because of that, the
whole project has gone far better than anticipated.
"We expected to generate code with a fair amount of bugs in it and to
have to spend time to fix them or override them so we could get the system
to do what we wanted it to do," Colburn said. "That's the first time I've
seen a code generator work that well. It allowed us to very quickly build
that graphical front end."
The proof-of-concept for the FPPS Web-based GUI was completed early
last month, and questionnaires were sent out to the user community for feedback.
After those have been returned and any concerns dealt with, Colburn expects
the FPPS system to be rolled out to the entire user community early next
—Robinson is a freelance journalist based in Portland, Ore.
Brian Robinson is a freelance writer based in Portland, Ore.