Database mix poses a sharing challenge; IS execs build ties when none available; find retrieval easier than distributed update - Client/Server Computing - includes a related article on important client/server issues

Software Magazine, March, 1992 by Barbara Bochenski

The fact that no all the exact pieces are available to build downsized, distributed systems where once there were centralized, mainframe systems, is not stopping IS organizations from downsizing.

The information systems staff at Amoco Production Co., Tulsa, Okla., has been working with distributed] concepts since 1983. Since no software suppliers offered products that met their needs for a distributed architecture, Amoco developed and prototyped its own solutions. Today the company is experimenting with vendor products, but they are not sure the products are ready for operational systems, according to Glen Thompson, research supervisor.

"Our products are just to help us do what we need to do until vendors provide mature products," said Thompson. "We're keeping a constant watch for products. We're also trying to influence vendor products so we can use them in the future," he added.

The IS staff at the Tucson Unified School District, Tucson Ariz., is going through a similar experience as they move their architecture from a centralized, host-based system to a distributed, client/server architecture. They make every effort to use commercial software products, but when a necessary function is not available in a package, the staff codes its own solution. (See story on page 68).

These and other organizations moving to a client/server environment soon confront the issue of how to share the databases. Not only must IS staffs address the traditional problems of sharing data--like mixing database models and database management systems (DBMSs)--but there are also new problems. These added complexities include dealing with network operating systems, local-area network (LAN) protocols and distributed computing. In response, some sites have dedicated staff members to learning these new concepts.

"I have a new position called an emerging technology specialist," said Jesse Rodriguez, director of information technology for the Tucson Unified School District. "When a new SDK [software development kit] comes out, I give a person the job of just learning all about this tool."

Such individuals need to know more than just the details of individual software packages. They also need to understand how various technologies work together. Can one software package be used when some and users are using Windows 3.0 from Microsoft Corp., Redmond, Wash., and others are using IBM's Presentation Manager? Can Unix users tap into a database stored on a server running OS/2? What if users on a Token Ring network using the Novell network operating system from Utah, want to use data that is stored on an Ethernet network using Microsoft's LAN Manager network operating system?

The answers to these questions vary depending on the mix of software. While client/server application designers still have to wrestle with many of the traditional problems of heterogeneous dat access, they also have a whole set of new problems to tackle.

DEFINING THE CONCEPT

The concept of sharing data in a client/server environment means different things to different people. To some, it means that data contained in a microcomputer database like dBase from Borland International, Inc., Scotts Valley, Calif.--originally used by one person or application--is now being shared by several users or applications (though technically this may actually be a file server environment). To others, sharing data in a client/server environment means that one client process can share or manipulate data that is contained on several different server databases.

"There are many examples of multiple clients sharing the same data on one server," said Larry Vaughn, senior consultant with Tekis, a technology integration firm in Gig Harbor, Wash. The major microcomputer databases, originally built for single users, can now reside on servers and be accessed by multiple users. "But it's still rare to see one application sharing data from two different servers," Vaughn said, noting that the latter is complex.

Shaku Atre, president of Atre/Intec, a software development and consulting firm in Rye, N.Y., which focuses on database issues, agreed with Vaughn about the complexity of sharing data in a client/server environment. "Going from one database to another is not that easy," said Atre, citing a number of issues that may arise. (See sidebar on page 75.)

Unix afficionados have more experience with distributed systems, since Unix was written to support multiple users. Unix was not designed, however, to handle multiple computers.

Vaughn noted that the more mature server databases like SQL Server from Sybase, Inc., Emeryville, Calif.; Oracle from Oracle Corp., Redwood Shores, Calif.; Informix from Informix Software, Inc., Menlo Park, Calif.; and Ingres from Ingres Corp., Alemeda, Calif., operate under Unix.

The Unix world provides a fairly uniform environment, said Vaughn, because protocols like TCP/IP and RPC (Remote Procedure Calls) are so widespread under Unix.

"As a result, it's fairly easy for a Unix vendor to provide a common method for programmers to talk to databases," he said. "If the Ansi Level 1 SQL standard is complied with, it's relatively easy to have one client talking to multiple, different databases in the Unix world."