Developing Workstation-Based Client/Server Applications Steve Rabin

Transcription

1 Developing Workstation-Based Client/Server Applications Steve Rabin Payoff Leveraging existing assets, both code and people, is one of the keys to successfully developing new distributed applications. This article describes a strategy for creating distributed client/server applications by combining code that currently exists with new code. Introduction Advances in workstation technology have historically outpaced corresponding software improvements. Sophisticated computer processing chips have, in general, been available years before the operating system software was able to exploit them (e.g., 32-bit processing technology was available on workstations well before any 32-bit software came out of the development laboratories). Application and corresponding systems support software has also lagged. The introduction of stable operating systems and environments has changed this situation, providing data base and network vendors with the opportunity to integrate their products with distributed platforms. In addition, a variety of software development tools are available that allow developers to create new applications that effectively use distributed environments. These environments are usually open or network-oriented systems using a Graphical User Interface and distributed Relational Data Base Management System. To successfully shift development to these workstation-based environments, it is critical that an organization: Understand what tasks must be performed. Have the right mix of people (and skills) to perform the given tasks. Agree on and stick to a common method of performing these tasks. Use effective, productive tools. Develop a distributed model. Implement a transformation strategy. Anticipate people, training, management, hardware, and software issues. Objective: Efficient Use of Resources Distributed applications need to be as portable as possible to maximize the long- and shortterm investment being made to the application. This investment includes its technological underpinnings, the planned production environment, and future production environments. Within the constraints of current business realities, for an organization to achieve competitive advantage with information technology it must efficiently use available

2 resources. Two key IS resources are current production applications and the employees who developed and are maintaining them. Distributed applications (where applicable) can be created by combining code that currently exists (possibly from a host system or even simpler workstation application) with new code. This combination makes the best use of existing(and still valuable) application code while allowing new code and its underlying technology to be efficiently integrated. The resulting new application code should therefore meet the organization's design criteria in a most productive and cost-efficient way. The blending together of old and new code involves the redevelopment of current application code. A determination must be made as to which portions of the code are still relevant and what, if anything, must be done to this code. This analysis process also lends itself to the creation of true platform-independent code that is, a single set of source code that can be operated on a variety of platforms and environments with some recompilation. This is a critical concept because no one can foresee all future production/development environments. As new users are introduced to the software, it is quite likely that the software will be required to operate on platforms that were not originally envisioned. All issues involving operating systems, diverse communications, data bases, graphical (and nongraphical) interfaces, and client/server technologies need be examined in terms of portability. Initial Workstation Development Considerations Applications used to operate the business and provide competitiveness are a valuable resource. In addition, IS professionals have acquired a wealth of information about those systems and underlying business principles. Any distributed workstation development project must consider techniques and methodologies that use current application assets in a cost-effective way. This approach allows IS management to combat several existing development dilemmas, including backlog of work, containing or reducing IS costs, incorporating new technologies to increase competitiveness, and using the large amount of existing application code and the expert knowledge that was developed along with it. Although this concept is not a new one, the idea of redeveloping older, outdated systems into new strategic systems is often overlooked. Because the concepts incorporate many of the best ideas of the past and present, this strategy can be successfully implemented in a wide variety of IS shops. It is not geared to any one particular methodology or environment and can be implemented in small, manageable, goal-oriented steps. Initially, an application is selected that requires modernization, either technically or functionally. For the purposes of this discussion, this means an application that is being developed to operate in an environment that includes: Distributed cross-platform operating systems, most likely Disk Operating System, Windows, OS/2, or UNIX. Client/server modeling to disperse application functions across the network. GUI front ends, most likely Windows, Presentation Manager, or Motif. Data modeling to distribute the data using a Relational Data Base Management System.

3 Communication facilities to handle multiple platform protocols(e.g., TCP/IP, APPC, or Internetwork Packet exchange). Although the goal may be to turn an existing application into a next generation, state-ofthe-art solution, this is not likely to happen all at once. It is better, especially for organizations new to distributed solutions, to phase the development of the system. This allows new tools and technologies to be assimilated into the organization while still providing ever-increasing benefits to the system's users. For example, the base functions of an existing Canadian Independent Computing Services Association application may be redeveloped for a graphically based client/server environment. The first phase of this project might be to port the front end of the Canadian Independent Computing Services Association system to a graphical workstation environment. This benefits the user and starts the development of graphical code and expertise that can be used throughout the remainder of the project. Later phases would include converting to a distributed relational data base, client/server functional modeling, and eventually incorporating support for all of the required communication interfaces (including host interfaces, proprietary systems, and currently popular platform protocols). Scope and Goals of Distributed Applications Development Once the application is selected and the business design issues are resolved, a variety of decisions must be made. The first of these concerns the target environment. It is always desirable to develop and execute the application in the most productive architecture possible. This may be a host, but distributed client/server or a combination of environments is the most likely architecture. Related user interface and communication issues must be examined. One decision will be whether a text-based or a Graphical User Interface makes the most sense. Similarly, will the system be Canadian Independent Computing Services Association -based or will another communications protocol provide a better solution? The distributed model also needs to be considered. This model is concerned with both the physical aspects of the application (and the enterprise it operates within) along with the conceptual aspects of how the business processes (and associated data) are to be split. Issues to be examined include whether key business processes will be performed on the client, server, or both, and where the data resides and how its integrity is to be ensured. Although there are several standard distributed models in use, it is easier to build and manage an application that only distributes data (and to a much lesser extent business processes) when it is an absolute necessity. Building a distributed application must be done in stages, and the last stage is data distribution. This facility requires close coordination between the program, data base, network, and associated middleware facilities. In addition, plans need to be made for the testing and maintenance of these distributed and potentially platform-independent applications. Cataloged test scripts help, as does development that follows a single source code strategy. An automated method of delivering and possible implementing the software may also be required. A method of delivering upgrades and fixes for distributed applications needs to be devised. Testing is an area that requires careful attention when processes and possibly data are being distributed and the platforms/environments are not homogeneous. Distributed processes include business logic and the graphical user interface (GUI) presentation. The logic needs to be tested on both the client and server, although the presentation may reside on multiple desktops. Distributed client/server testing tools are becoming available to help

4 execute testing procedures, but they are not a replacement for a sound testing methodology. A simple example illustrates this point. An error is found in the Windows program of a user data entry screen. This screen is also displayed to Presentation Manager and Motif users. Does the error also exist in these environments? Is the correction made to the Windows program the correct one for the other environments? Assuming that it is, is the correction made carefully so as not to introduce new errors? These are all critical issues in distributed testing that a tool can help with but not solve. Redevelopment Strategy Open environments offer a variety of benefits, but they require careful planning, a sound methodology, and a suite of integrated design, development, and maintenance tools. A single set of source code that can operate on multiple environments is the answer to many of these issues. It solves the problem of multiple sets of source code for specific environments and code integrity. All of the distributed applications development work described in this article can be accomplished using Common Business Oriented Language. This is true of all of the operating environments and all aspects of the code, including communications and Graphical User Interface interfaces. This approach is recommended because many existing systems that are critical to the success of their businesses are mainframe and COBOL based. In addition, most of the systems people are trained in COBOL and its host environments (e.g., Canadian Independent Computing Services Association, Internet Multicasting Service, and data base 2). IS organizations need to understand that their COBOL investment can fit in with strategic efforts for future systems. This approach does not exclude other or mixed technology solutions; in fact, in certain instances they make sense. It does, however, emphasize that the mass of older application code can be profitably used across a variety of platforms and environments. Because the changes implied throughout this article have an impact on many business disciplines, organizations are having to recruit the support required to complete what is usually a multiyear effort. IS can offer short-term deliverables within the longer-term strategic goals using certain fundamental principles and tools. Fundamental Development Guidelines Many questions come to mind when examining distributed development, usually pertaining to learning a new language, understanding multiple graphical user interface (GUI) APIs, data acquisition, and communicating between platforms. There is no reason to switch languages. Tools are available to handle the multiple graphical user interface (GUI) environments, and distributed DBMSs are accessible with Structured Query Language. Even platform-to-platform communications issues are simplified by several high-level tools. When developing applications in and for a new platform, several basic development guidelines still apply. These include: Developing a conceptual development strategy. Determining technical and functional development guidelines. Determining technical and functional application guidelines.

5 Converting the conceptual development strategy into a logical transformation strategy. This analysis is usually performed by a combination of automated analysis and oldfashioned desk work. People from the business and data processing sides of the application work together as a team. The organization, not IS, is creating a strategic system capable of taking the business through the end of the century. Experience has repeatedly shown that certain fundamental practices must be in place before beginning a distributed development project (or any development project for that matter). First, a software development life cycle and methodology must exist. Second, policies and procedures for accepting and controlling deliverables must be implemented. This situation is equally true for a developer completing a program change or the project team completing the entire distributed system. Programs in the system will be expected to operate in different environments and must be tested accordingly. Finally, these points must be well defined and understood by all concerned. The organization must believe in and see the benefit of these methodologies and procedures if it is going to use them. Extending the Existing Development Strategy Although training is going to be a requirement, because developers need to understand the new platform and environment in order to be productive and design an application that makes significant use of its facilities, the bottom line is that a project can and should be implemented using a methodology and techniques that are similar to those currently in place. In areas where the methodology needs to be revised GUI design, for example it is an extension to the existing development strategy. Similarly, a new tool is an extension to the tool set and not a new development workbench. The point is not to minimize potential changes being made to the code but to explain that these changes are evolutionary and must be integrated into the existing environment and organization design strategies. As shown in Exhibit 1, the time and tasks required to complete client/server projects are closely related to traditional applications development. Client/Server Development Transformation Methodologies The heart of the distributed development process is the transformation methodology, which combines the business and technology visions into a coherent whole. This method is actually the coalescence of top-down (business vision)and bottom-up (technical vision) approaches. The result is the overall organization transformation policy: a strategical statement or contract defining what the system will be and what it will take to get there. The top-down strategic input is required to understand the business vision. This input determines what the requirements of the new application are, or if it is an existing application, what needs to be revised. The prospective users of the new system and the environments in which the system is to be employed are also part of the business vision. The bottom-up tactical input is required in order to understand the platform, environment, and technical issues of the new system, and to analyze the composition of the existing system, including data, program, process relationships, and associated

6 software/hardware requirements. From this input, short-term deliverables can be identified under the long-term transformation strategy. The last part of this phase is to determine feasibility and conformance to the vision. This takes participation from the business and IS sides, preferably in face-to-face meetings. It must be technically feasible and reasonable to develop and implement the business vision. If, for example, the business vision requires a palm-size, pen-based color computer with distributed networking capabilities, an evolutionary implementation may be required until the technology is both workable and available. By no means should the business vision be cut short or revised by the IS organization, but it is the responsibility of IS to explain to corporate executives what it takes to meet the business vision. A technical compromise may be necessary in order that the business functions can be properly implemented within a reasonable time frame and the design of the system meets the target audience's needs in a meaningful way. Code Development Functional Analysis Once the plan is formalized and in place, the business of developing the system can begin in earnest. An analysis of the existing base of application code should be done to identify overlapping functions that is, functions the target system and currently existing systems have in common. There are many application-specific functions that can be used in the new system without change (e.g., date routines, calculations, and report formats). It is important to use this existing base of code because it is both proven and understood by the professionals developing the new application. Leveraging existing assets, both code and people, is one of the keys to successfully developing in new environments. Because these functions may be used repeatedly during the development process, reusable code libraries or repositories should be developed. In addition to determining functional code that already exists, all other functions should be identified and cataloged. It may be that some of the target functions are excellent candidates for code generation (if that is available). Once the functional analysis is complete, a wealth of information should also be available about existing code and new system processes (i.e., how the system is to accomplish its functions). This information is critical when existing processes and underlying code are to be used as much as possible(in one form or another). Data Requirements Functions, processes, and the application code comprise only half of the equation. Data relationships and requirements must also be defined. Distributed data models for the target system need to be analyzed and cataloged. A data repository is an excellent means of tracking the data requirements of the system and ensuring the data is not duplicated. Equally important, data residence needs to be established if the data is to be truly distributed. The host, servers, and local workstations may each contain information critical to the application as a whole. The analysis of data representations in the system often indicates where improvements can be made. Common problems include redundant data and inconsistent data use. It is not

7 unusual to discover that some of the required data remains undocumented, a situation that must be corrected. Modernizing data representations involves careful review of the design and (where applicable) the code. This involves identifying key data structures and where and how they are manipulated, as well as standardizing data names and definitions and propagating them throughout the system. Finally, data access methods should be reviewed to determine the means by which data will be acquired in the target environments. Assembling Platform-Independent Code Once the processes are isolated so that the platform-independent nature of the code can be formed, the application code can begin to be reassembled. To take advantage of specific environments, it may be necessary to symbolize the code. Symbolization is simply a process of adding code that is assembled at compile time, most likely using a precompiler. Although this is not a requirement of distributed applications or platform independence, it provides certain advantages. A simple example is taking advantage of a monitor that displays 44 lines of data rather than the more traditional 25 lines. The Problem of Diverse Interfaces One of the major issues of coding for diverse environments is the many APIs that are encountered. This is especially true for data acquisition, Graphical User Interface presentation, and communication protocols. Standardizing around Structured Query Language and data bases that support distributed data access provides a solution to the data issue. graphical user interface (GUI) presentation is not as easily solved without the use of a tool. Several sophisticated tools are available that provide a common interface to many of the prevalent graphical user interface (GUI). A more detailed look at the communication issue helps explain how a single set of source code handles diverse interfaces. The use of tools that support a Common Communications Interface or Application-to-Application Interface allows the same code to execute across platforms, regardless of the protocol. APPC, Named Pipes, NetBIOS, and Internetwork Packet exchange are several of the communication protocols that can be used to provide distributed services. An application can have access to both individual environments and distributed open environments in this manner. This allows the same source code to elegantly handle the complexities of distributed communications. Exhibit 2 illustrates this concept. Communication Facilities for Distributed Services In a distributed applications environment, each of the isolated functions must be tested as a coordinated whole under all target environments. The same code may be required to operate under Disk Operating System, OS/2, Windows, or UNIX. Similarly, the integrity of the code must never be compromised. Regardless of the platform, the code operating on a single, secure version must be maintained.

8 Distributed Development Tools There are many Common Business Oriented Language-oriented development and maintenance tools that allow developers of distributed, workstation applications to take advantage of the techniques described in this article, including tools that provide crossplatform support and are compatible with code initially developed for other environments. Workstation-based tools are available that support development for Disk Operating System, Windows, OS/2 Presentation Manager, UNIX, and UNIX Motif. These tools use a variety of platform-specific runtime environments so that the code need not be developed to that level of detail. When the application code is developed at a higher level, it is possible for the same source to execute in diverse environments. For example, the Micro Focus Operating Systems Extensions (OSX) environment provides COBOL programs (and thus COBOL developers) with the same services and the same interfaces for all target operating environments. Applications developed on one system can be ported to another with minimal, if any, code modification. Other tools enable developers to prototype and create graphical and character-oriented user interfaces that can be ported across all target operating environments. A set of communication and Structured Query Language data base services tools support high-performance application interfaces to a variety of networks and data bases. SQL services provide support for Gupta, Microsoft SQL Server, NetWare SQL, Oracle, OS/2 Database Manager, Informix, Sybase, XDB, and others. Application-to-Application Interface and Common Communications Interface provide network and client/server support. application-to-application interface (AAI) allows program-to-program communication between platforms that is, one program can call another program as if it were a localized routine. common communications interface (CCI) supports network (and internetwork) application communications. Distributed testing tools must operate on multiple platforms and have the ability to visually analyze the program logic and determine how much of the code is actually being executed during the test. A tool that provides the developer with a common interface across platforms is critical because developers may encounter a situation requiring them to test a function in an unfamiliar environment. Because less specific skills are needed for distributed applications development, selecting the definitive computing environment is a much smaller issue because applications can be moved to other platforms. Most important, scarce development resources can be used where they will have the greatest impact, developing business application code. Conclusion Distributed applications provide many benefits to the organization. They allow both business and systems professionals to solve problems while positioning their companies for the future. In many cases, code from existing systems can be salvaged and turned into high-quality, next-generation applications. Development staff members are already familiar with the code and, to a certain extent, the basic methodology and tools. It is not necessary to reinvent the wheel. The key design criteria to be taken into account before moving applications development to a distributed client/server environment include: Process models.

9 Data models. Object distribution. Repositories. Stored procedures. Language. Program modules. Communications. Desktop presentation (GUI). Distributed platform testing. Application distribution. These criteria should be assimilated into the development process using the transformation strategies described in this article. In some respects, distributed applications development is different from other systems development efforts for mainframes, midranges, and standalone workstations, but there are similarities in the way the project should be approached. Data modeling, process design, function analysis, and prototype acceptance are examples of tasks that are performed in all structured applications development projects. It is not necessary or even advisable to get wrapped up in the technology. The ultimate tool, methodology, or environment is always going to be out there waiting to be discovered. A better approach is to take small, measurable steps with definable goals and allow the project to generate momentum with initial successes toward the organization's ultimate goals. Author Biographies Steve Rabin Steve Rabin is director of application development technologies at American Software, Inc., in Atlanta GA. He specializes in workstation-to-host communication packages, networking environments, and distributed processing systems. Previously he was manager of the field systems group at Pfizer Inc., responsible for the design, development, and implementation of manufacturing, distribution, and financial applications at facilities around the world.

10

11