When Paul Dupuis, the Assistant Director of Information Technology at Boston College, made the decision to graduate the university to a Java-based E-mail environment, he knew it would be an experience rich in learning about new programming paradigms and thin-client architecture, among other things. The one topic he clearly doesn't expect to study: bandwidth constraints of the new application on his campuswide network.
Dupuis, who is leading the charge to Java-based E-mail and network computers as a more cost-efficient means of automating the Newton, Mass., university's work force, doesn't foresee the new architecture placing any additional burden on his network--at least initially. "We didn't expect any problems because we have users who are working with other electronic-mail systems, and their transmissions have never created a network bottleneck," Dupuis said.
Lured by the promise of faster development, simpler application portability and a cost-effective, easy-to-maintain thin-client architecture, corporations and universities such as Boston College have begun to rewrite mainstream applications in Java, a programming language conceived at Sun Microsystems Inc. and administered by its SunSoft division, both in Mountain View, Calif. Despite the promise of these applications, however, there have been concerns that the new breed will create widespread network bottlenecks, slowing throughput to a crawl.
"Many companies are moving slowly to Java because they fear that departments will deploy applications so users will be continuously downloading large files from Web servers," noted David Passmore, a principal at Decisys Inc., a Sterling, Va., network consultancy.
To date, however, such concerns have mainly been unfounded, with many early Java pioneers reporting no such bottlenecks. These organizations have deployed mostly small, simple applications designed for 50 to 100 users. As part of these controlled rollouts, companies are giving users access only to limited amounts of information, hoping to prevent network overload.
Yet because most companies have not deployed mission-critical, Java-based systems that support thousands of users, experts say the potential for network logjams still exists. But with the right planning, companies can continue to be selective in what information users can shoot across corporate networks. And future improvements to browsers and NCs could help companies circumvent any potential network impasses. "I really don't think Java will have as much of an impact on corporate networks as some MIS managers fear," added Decisys' Passmore.
Pilot mode
Experts say much of the reason the bandwidth issue has remained in the background is because corporations are just starting to dabble with Java programming, because the language is still lacking in its ability to support large workgroups, has significant memory requirements and offers limited third-party programming aids. Observers expect Sun and third parties to smooth out the rough spots by the end of the year, accelerating the speed at which corporations deploy Java in business-critical systems.
"Many companies are in pilot mode with Java," said Ted Young, CEO of Advanced Web Technologies Corp., a New York consultancy specializing in Java. "To gauge its potential pluses and minuses, they are working with Java E-mail systems or putting simple Java front ends on legacy applications."
Boston College certainly fits that bill. The university has placed PCs on approximately 2,000 employee desks, but there are still 500 full-time and 1,500 part-time workers--for example, campus security--who don't have access to the university network, said Dupuis. Ponying up $3,000 per PC for each of these employees is too costly to justify more widespread network access, he said. Instead, the Boston College IT group is pushing network computers and Java-based software as a more cost-effective and efficient platform.
The first step in that process was to select a Java-based E-mail system. Earlier this year, Boston College chose PonyEspresso from i-Planet Inc., of Sunnyvale, Calif., mostly because it was one of the first Java-based packages available. The software was tested in the early summer on NCs from Idea Associates Inc., a division of Idea Corp., of Bedford, Mass., Apple Computer Inc. Macintoshes and IBM RS/6000 servers. Dupuis' group found no major impact on the college's shared 10M-bps Ethernet connections. The university plans to roll out PonyEspresso to 50 users this fall and will expand use by the end of the year.
Phillips Petroleum Co. also managed to avoid any network performance problems when it launched a pilot Java application to monitor data on its pipelines. The company looked to the Java-based program to automate the compilation of performance information on its pipelines, which span 6,000 miles across the United States. The existing system relied on 164 PCs running Microsoft Corp.'s Windows 3.1 to monitor how petroleum flowed in the pipelines. Operators stationed near the PCs examined usage information and manually faxed any problem data to Phillips Petroleum's central site, where technicians could make routing changes on applications running on an IBM 3090 mainframe.
To automate this collection process, Phillips Petroleum decided to write an application in Ambrosia, a Java programming environment from Open Horizon Inc., of San Francisco. "We decided to go with Java because it would help us speed application development," explained Michael Guidry, a project manager at the Bartlesville, Okla., petroleum company.
The application, which was completed early this year, transmits performance data to an Oracle Corp. DBMS running on an IBM RS/6000 server. Rather than install new network connections, the petroleum company decided to rely on an existing satellite network that operates at 56K bps.
The impact of putting the new application on the network has been minimal. In some cases, Guidry said, it has actually helped rather than hindered performance. The reason, he explained: the way Phillips Petroleum controls the amount of data transmitted and when it is sent. By designing the application to automatically send information at specific times, the company was able to eliminate the overhead of a polling mechanism that would periodically dial up remote locations and download performance data. Phillips also sorted the information locally so only small packets of information--rather than huge files--were transmitted over the network, he explained.
Boston College and Phillips Petroleum are only steps ahead of a third company working with Java: Lockheed Martin Corp., which designs the space shuttle for NASA. Lockheed turned to Java to upgrade a
2-year-old document management system for enabling engineers to share drawings, tables and text, according to Don Clark, a staff engineer based at a division in Marshall Space Flight Center, Ala.
The Lockheed employees responsible for the design and upkeep of the U.S. space shuttles are stationed in four locations: the Marshall Space Flight Center; Downey, Calif.; NASA, in Houston; and the Kennedy Space Center, in Cocoa Beach, Fla. The custom-designed system lets Windows 95-based users access information stored on Sun UltraSPARC station servers running Oracle7; it would not allow employees on Macs or Unix workstations to tap into the document database.
This heterogeneous environment precipitated the need to rewrite the application in Java, according to Lockheed Martin's Clark. About 20 percent of the application is now finished, and Clark expects the revamped document management system to be running by the end of the year.
Given that engineers can download documents at will and that there are now 50,000 documents stored on the Sun servers--many of them large and complex--Lockheed Martin represents the best case for potential network problems. But Clark isn't anticipating any for a couple of reasons. The company has been tinkering with the Oracle7 database so users only download small portions of files--for example, one page of an engineering drawing--rather than complete files. Also, Lockheed Martin already has a lot invested in network bandwidth: It employs 10M-bps Ethernet connections to user desktops, multiple T-1 lines and T-3 lines, which transmit information at a rate of 45M bps between the four sites.
Although such pilot applications are safely under way, experts agree there will be a second wave of Java-based systems that are almost certain to put more of a strain on corporate networks. In addition, some inherent limitations in the language need to be squared away. While portability is theoretically a Java strong point, Advanced Web Technologies' Young said companies often have difficulty realizing that benefit. Java features a virtual machine interface that enables programmers to work with higher-level APIs. But Young said the first virtual machine iterations for Java were unstable and did not support as many features as programmers desired.
Moreover, browsers have not efficiently implemented Java, said Stewart Allen, vice president of engineering at Web Methods Inc., a Fairfax, Va., third-party software developer specializing in Java. Specifically, their memory requirements run counter to the thin-client programming model, said Allen.
Another shortcoming stems from the initial capabilities in Java as Sun conceived it. Shaun Maine, chief technology officer at Java application developer Sanga International Inc., in Toronto, said the first versions of Sun's Java Software Development Kit supported only small workgroups (10 to 12 users) and could not scale up to support more sophisticated applications.
Analysts expect these problems to be gradually resolved as Sun and third parties deliver more Java products. They anticipate companies will begin building more sophisticated Java applications in early 1998.
How these next-generation applications perform on corporate networks boils down to a question of design, according to the experts. Boston College's Dupuis plans to put that theory to the test. In the second stage of its migration to Java-based systems, the university plans to build a class registration system based on Oracle.
"We don't think Java by itself raises any new network concerns," said Dupuis. "If an organization designs an application well, then it will not cause any network problems. If a design is poor, all sorts of problems are possible."
Source Citation
Korzeniowski, Paul. "Java: no bandwidth hog." PC Week 14.43 (1997): 133+. General OneFile. Web. 3 Jan. 2011.
Document URL
http://find.galegroup.com/gps/infomark.do?&contentSet=IAC-Documents&type=retrieve&tabID=T003&prodId=IPS&docId=A19896974&source=gale&srcprod=ITOF&userGroupName=22054_acld&version=1.0
Gale Document Number:A19896974
No comments:
Post a Comment