Windows Shopping: Georgia Tech Research Institute Automates Its Windows Applications, Part II

• 04/01/2001

Part I

According to Watson, the problem of applications not getting along first appeared several years ago – back in the Windows 3.1 days – with less complex spreadsheet tools, such as Lotus 1-2-3 and Microsoft Excel. "The installation of one product would downgrade the shared components of the other," he explains. "Basically, the last product installed would operate just fine, but would cause the previously installed product to fail whenever someone wanted to execute it."

Even with recent, noted improvements in MS-Windows stability and reliability, the problem has continued at the application level in subsequent, modern versions of the operating system and revolves around the large number of shared components – DLLs, registry settings, COM modules and application files – used throughout the enterprise environment.

"We became painfully aware of the fact that you could break something else whenever you installed a new piece of software," explains Watson. "To ensure the continued integrity of our applications, we needed a way to automatically protect deployed applications from themselves and find a way to identify the hodge-podge of shared application components on all of our desktops and servers."

Prior to the potential for large-scale deployment of shared component conflicts, GTRI had dozens of Oracle applications distributed throughout its environment. Some applications, for example, use data extracted from Oracle databases as input to a series of Lotus 1-2-3 applications. Other applications, built using combinations of PowerBuilder, Java Script and HTML, centralize data from multiple Oracle databases into a single user presentation.

But, the planned implementation of additional packaged applications – PeopleSoft and Banner – revealed that the potential for conflicts with GTRI’s applications throughout the enterprise would be extremely high.

"We discovered that Banner and PeopleSoft could not be run on the same desktop with GTRI’s applications," said Watson. "And then, we found that our newest version of Oracle Discoverer, Oracle’s ad hoc query tool, also would not work with PeopleSoft or Banner. Through all of this, our goal was to resolve all conflicts and pre-test prior to deployment."

The first option explored was to write scripts that would redirect program execution and force the usage of the components specifically required by the individual applications. However, the number of shared components, combined with the number of desktops, would have made the development and subsequent maintenance of the scripts virtually impossible.

"It’s possible that we would have required a unique script for each desktop," Watson explains. "But, each script would need to take into consideration the configuration of each individual desktop. That translates into hundreds upon hundreds of unique scripts that would require modification whenever changes occurred to the desktop. And, there was no way we could truly keep track of the contents of each individual desktop."

The second option would have been to install a separate computer on the desk of each user requiring access to the unique applications. For example, a person requiring access to PeopleSoft and Banner would have received two machines and a person requiring access to PeopleSoft, Banner and GTRI’s applications would receive three. "Certainly not an effective, cost-justifiable solution," Watson says, citing GartnerGroup estimates of approximately $9,600 per year to support each individual desktop PC. "It makes no financial sense to add nearly $10,000-$20,000 per year, per person in PC support costs for one or two applications."

Instead, GTRI implemented WALLS to help analyze, package and insulate applications. Using the WALLS Integration Lab component, the technical staff at the organization pinpointed from each desktop and server the shared application components, versions and registry settings, as well as application compatibilities and, more important for ensuring quality deployment and high availability, any incompatibilities that would have resulted in application failures. "Understanding the differences in the internal application components is a crucial step in ensuring the integrity of the applications we need to deploy," says Watson.

Also, as part of the WALLS analysis process, all information can be stored in the WALLS Application Knowledge Base(AKB), a component of the product that actively monitors and maintains a comprehensive cross-reference of application components, resource requirements, processing requirements, machine contents and application intersections. The AKB also serves as the baseline for performing application comparisons where technicians can quickly pinpoint the differences, similarities and conflicts between applications residing on different machines.

"Armed with complete knowledge of all the application components, we were able to immediately identify and resolve conflicts prior to deployment," explains Watson.

For example, a newly developed application containing a state-of-the-art interface capability may employ the most current versions of MS-Windows common controls and dialog modules, such as COMCTL32.DLL and COMDLG32.DLL and the Visual ‘C’ runtime module MSVCRT.DLL. But, while the application may run fine on a single machine, introducing it to a different machine within the enterprise environment can result in failures as older versions of these controls and modules may be in place. "WALLS analysis, though, provides us with the detailed information regarding the most common types of conflicts, such as those with DLLs, registry settings and COM modules and helps us eliminate errors prior to a production deployment," says Watson. "WALLS provides us with predictive capabilities that improves the quality of the applications that are about to be deployed."

According to Watson, understanding the complexity of applications is only the first step in helping to ensure the stability of deployed applications. In fact, for some companies it can be a frightening step as they quickly gain a picture of all the possible conflicts – and potential highly-visible application failures – within their environment.

"What’s needed after the application knowledge is delivered and all possible conflicts are identified is a way to make sure that applications can successfully execute without writing complex scripts or installing additional computing power," says Watson.

To effectively protect applications from one another and enable them to successfully operate on a single desktop, GTRI employed the WALLS Insulation component. WALLS Insulation provides GTRI with the ability to define a unique, application-specific module and registry load environment that can automatically act as an override to the normal Windows search.

"WALLS Insulation allows us to create unique directories and paths for each individual application," explains Watson. "It also automatically and transparently directs the application to operate and execute from the specific load environment instead of the Windows system environment."

WALLS Insulation support extends to include overriding of DLLs, registry settings, COM modules as well as modules in the MS-Windows KnownDLLs list – a Microsoft method for ensuring that only a single version of the module exists on the desktop for users of the module, which are defined in the registry keys associated with the local machine. Unfortunately, using the KnownDLLs list at GTRI was impractical as different applications required different versions of the same DLL. "We needed to have multiple versions of the same-named DLL on many desktops," explains Watson. "WALLS Insulation was the only way we’re able to effectively have different versions of the same components residing on the same desktop."

According to Watson, using WALLS Insulation is a straightforward task. As part of the WALLS Integration Studio, application insulation can be a result of the Application and Component Library functionality. This functionality allows IT professionals responsible for the deployment of applications to analyze application requirements and components, and create packages containing the proper versions and proper elements needed for successful deployment. Packages containing properly connected and configured application components can be installed using existing software distribution products, such as Tivoli or SMS, that perform installs using Microsoft’s new Windows Installer, supported under Windows 95, 98, NT and 2000.

Walls Application Insulation enables the application installer to determine the set of resources assigned to the application and from where to retrieve them. A Library is the repository of these resources. Libraries are critical to maintaining application reliability when an application uses shared components. Using Libraries also simplifies installing incompatible applications since each can have its own set of component libraries. Backing out an application to a prior version requires a simple configuration change to direct the application to use the prior versions’ component Library. Notes Watson, "There is no need to reset modules and registry keys after a backout since these are all self contained in the Library."

Helping to avoid additional conflicts and further ensure the integrity of applications, GTRI opted to insulate Oracle Discoverer and every GTRI-developed application using Oracle. "We wanted to make sure that our internally developed systems didn’t conflict with the packaged systems," Watson explains. "Insulation allows us to place new installs directly into the appropriate WALLS directories without impacting any other application."

Insulated applications are configured to reference either a WALLS Shared Component Library(SCL) or an Application Component Library(ACL). A Shared Component Library is shared by many applications while an Application Component Library is specific to a single application. For example, a Shared Component Library could be created for MDAC 2.1, or for chosen modules currently residing in the Windows System or other common directories.

While Windows 2000 helps address some of the problems of shared components with Side-by-Side components, GTRI plans to continue to use WALLS Insulation even after they finalize migration to the new operating system. That’s because, according to Watson, the registry insulation functionality provided by WALLS is not possible within Windows Side-by-Side. "Unlike WALLS, Windows 2000 requires that we change application code to take advantage of Side-by-Side and still does nothing for insulating registry settings," he says. Furthermore, he notes, that WALLS Insulation can be used regardless of the version of Windows. "Insulation is the best method for ensuring that all applications are protected from one another."

Equally important, Watson contends that in an environment comprised of both a large number of vendor products and internally developed applications, WALLS Insulation is absolutely crucial. "While it’s possible that we can change our own code to avoid conflicts, the question is: ‘Why should we?’ Besides, it is not possible to go to each and every vendor and request that they change the code within their products. With a large number of purchased products mixing with our own, we cannot live without WALLS Insulation for registry settings," he says.

WALLS has helped GTRI to successfully deploy applications that don’t get along together, by creating packages, identifying conflicts and insulating executables, Watson notes that it has simplified the overall software quality and deployment process.

"WALLS packaging and insulation allows us to place applications in isolation for testing," he says. "We can test the application from an insulated library and know that it works. Then, we can use our installer tools to automatically perform the distribution. We no longer need to send a technician armed with a CD to each desktop."

Furthermore, Watson contends that WALLS helps GTRI keep better tabs on its large, complex inventory of application components. "It maintains all component listings and versions within its database and let’s us know if we receive a component that’s contradictory to our requirements."

The most important item, however, was that WALLS easily justified itself when costs were compared to either writing/maintaining custom redirect scripts or installing separate machines on the desktop of so many users. "WALLS has paid for itself many times over by helping us to automate the software deployment life cycle and improve the quality of our Windows applications," says Watson. "We’ve found that you can’t support Windows without WALLS."