Mainframes make Web connection

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

system's future.

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

browsers."

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

time.

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

year.

—Robinson is a freelance journalist based in Portland, Ore.