By David S. Linthicum
DBMS, July 1996
Selecting a client/server development tool is one of the most challenging tasks in the world of client/server. The number and types of tools change so quickly that it's difficult to keep up. Each tool differs greatly in features and capabilities, and it's often difficult to rely on marketing literature for the information you need to make the right selection.
To make matters worse, unlike other enabling client/server technology, the penalty for selecting the wrong tools is severe. Many a failed client/server development project can trace critical problems back to bad tools. What's more, the wrong tool for the job can double the cost of a project, or result in lost end-user productivity.
First, it's helpful to understand how system requirements fit in. The trick to selecting the right client/server development tool for the job is to go from the application requirements to the tool, and never from the tool to the requirements. This means that you must understand the application requirements completely, and compose a list of features and functions that the tool must possess to meet those requirements or the criteria. Table 1 hows sample criteria to use when selecting a tool.
For example, an application may require a connection to an obscure legacy database, as well as a connection to a messaging system and the ability to utilize bar codes. Those requirements (and many others, I'm sure) become the criteria to select a development tool.
Because most applications have some unique requirements, there is no single set of criteria that you can use to select a client/server development tool. However, there are some common requirements such as repositories, object-oriented development, database connectivity, component integration, cross-platform support, and three-tier and n-tier support.
Repositories in development tools let you layer things such as validation rules, fonts, colors, and relationships on top of the physical database schema. You build an application on top of a repository, which automatically inherits the characteristics of the metadata. The idea is to set up all this information once and reuse it throughout the application.
Using repositories, maintenance activities become easier because you can perform global changes by changing a single item in a repository (for example, changing the attributes of a column). A good tool propagates the changes throughout an application through the object-oriented concept of inheritance. You can usually override the repository when required.
Some repositories also store application objects along with other data-related repository information. You can reuse these application objects from the repositories, and sometimes repositories are shareable among developers in a project team environment.
Most specialized client/server tools such as Powersoft's PowerBuilder, Symantec's Enterprise Developer, JYACC's JAM 7, and Compuware Corp.'s Uniface provide repositories. However, each tool implements its repository in its own special way. For example, PowerBuilder's repository, known as the Extended Attribute Set, is stored in the database along with the data. This lets you build on the simple schema information in the database. PowerBuilder lets you specify extended attributes for each column, which lets you attach application-oriented information (for example, display formats, validation rules, initial values, and header or label text) to columns for use throughout the PowerBuilder application. Thus, you can specify application standards.
You have to build the database sometime, and you might as well have the power to do it right from your client/server development tool. A database design facility lets developers and DBAs create entire databases directly from the same tool in which they build the database application. You have an easy-to-use design facility, as well as the capability to generate the native DDL.
Most database design facilities, such as those found in PowerBuilder and Symantec Enterprise Developer, provide graphical diagramming capabilities that resemble CASE tools. These tools let you create icons on the screen that represent tables in the database. You can set the relationships when you link the icons together by common keys, usually using a drag-and-drop facility. Once complete, the tool can generate the DDL automatically and create the objects in the physical database. Some tools let you roll back database changes.
Some tools support database design through crude SQL interfaces, which require you to write the proper SQL code, and some tools require you to use external facilities such as CASE tools to create and alter a database. These are less desirable characteristics.
Tools should support most popular databases, including Oracle, DB/2, Informix, and Sybase, using native 32-bit drivers, and should offer support for many other databases through ODBC. Database connectivity should be built directly into the tools, so you don't have to integrate third-party middleware. Some tools let you tune the application for a particular database. For example, setting cache size, buffer size, bucket size, and so forth can help meet the particular needs of the application using the database server.
In addition, the tool should be decoupled from the database server. In other words, you should be able to swap out databases quickly, making only minor modifications to the application. Tools should also support heterogeneous database connectivity, or the ability to connect to more than one brand of database server at a given time, or multiple servers running the same DBMS.
A less common tool feature is an application design facility that lets you model the processes. Generally speaking, most development tools leave this to CASE tools and methodologies (for example, Booch, Coad/Yourdon, OMT, and so on). However, most specialized client/server development tools provide simple mechanisms to do things such as browse an application's class hierarchy. This lets you view how each object interacts with the others and move objects around to structure the application better.
Application partitioning tools such as Forte and Dynasty provide high-level application design facilities, letting you define application objects in a single environment and then partition them to available application servers accessible by a network. Once the objects exist, you can move them to application servers for realtime processing by dragging and dropping them inside the application partitioning facility. Although this is a functional process, it's an example of an application design facility built into a development tool.
Most client/server development tools use an object-oriented development model. However, they do so in different ways. Object-oriented development, simply put, means that a development tool or language supports inheritance, encapsulation, and polymorphism.
Using an object-oriented model, a tool can separate an application into classes and objects (instances of a class), or self-contained modules that encapsulate both the data and the methods that interact with the data. Inheritance lets developers program from the generic to the specific, reusing as much code as possible. If designed correctly, object-oriented systems are easy to build and maintain.
Some tools support multiple inheritance, or the ability to inherit data and methods from two classes, combining them in a single class. Although this is sometimes nice to have, it's a dangerous practice. Combining methods and data can cause conflicts, and they are difficult to diagnose in an object-oriented environment because the problems actually exist in higher-level classes. Therefore, use multiple inheritance at your own risk.
Programming languages give you the ability to make the application manipulate data and set or alter properties of controls, forms, and dialogs, as well as access disk files, invoke the operating system's API, and many other low-level processing tasks. Keep in mind that the tool should emphasize graphical design and minimize the amount of hand-coding necessary.
Most client/server tools provide fourth generation languages (4GLs), or high-level languages (sometimes called scripts). These are often proprietary languages.
The programming language needs to provide typical operators such as if-then-else and looping logic. Programming languages should also let you manipulate the database directly. Moreover, the programming language should provide object-oriented features, meaning support for inheritance, encapsulation, and polymorphism, not procedural programming.
Client/server development tools need to have an efficient application deployment mechanism, or the ability to distribute runtime versions of the application to end users. This should be royalty-free. Most client/server tools compile applications for distribution, but the differences lie in the compiled code.
Typically, client/server development tools provide p-code interpreters. This means that the tool creates a file that must be interpreted at runtime into machine language for the processor. This provides an easier development environment because the code does not go directly to the processor as a native executable, but performance can suffer. A few client/server tools (such as Delphi), as well as most 3GLs, provide true compilers that create native executables, which are preferable.
No matter what deployment mechanism the tool uses, application performance varies greatly from tool to tool. Performance is critical because it's how the user perceives the application. Performance problems are difficult to solve with faster processors because it's inevitable that lower-powered clients will run your application.
There are two performance considerations: application performance and database performance. Client/server tools should provide consistent application performance when painting screens, displaying data, and jumping quickly from screen to screen. Doubling the number of objects in an application should not greatly affect the performance of an application.
Tools should access databases quickly, moving the data efficiently from the physical database over the network to local memory. Although much of this is dependent on the capabilities of the database server, application performance should not change when the size of the database increases. Measuring performance should not be a subjective process (for example, "seems fast"). To obtain valid results, you should compare tools in the same category, using similar configurations (for example, database, middleware, and so on).
Today, the key to quick development is the ability to build as much of an application as possible from prebuilt component parts. Client/server development tools should support standard components such as VBXs and the newer ActiveX (formerly called OCX) controls. Tools that don't support components lock you out of a world that could potentially save you a lot of money -- as much as 50 percent of the coding time, depending on the project.
Components are added in as objects to applications to solve particular problems, such as the need for a built-in calculator, access to middleware layers, or high-level financial calculations. An application can be made up of many components that were either developed in-house, or better yet, purchased from third-party vendors.
Cross-platform support promises that the client/server tool will support more than one operating system and GUI. This means that you can write an application one time, then port it without modification to other platforms. Some tools allow porting to similar platforms such as Windows 3.11, Windows 95, and Windows NT (I call these second-tier tools). Others support very dissimilar platforms, including Unix, Macintosh, and OS/2 (I call these first-tier cross-platform tools).
There is a tradeoff to cross-platform support. When a tool supports many different platforms, it has a tendency to do no single platform well. Applications running on many of the supported platforms lack a native look and feel or have performance problems. Therefore, it's a good idea to use cross-platform tools only if you really need them.
When considering cross-platform tools, you need to consider development platforms vs. deployment platforms. Some cross-platform tools only let you build an application on a particular platform (for example, Windows 3.11). Once an application exists, you can deploy it to other platforms that the cross-platform tool supports. However, changes to and debugging of an application must occur on the originating platform.
Scalability refers to a tool's ability to support a growing number of clients. Many specialized client/server tools don't scale well. Applications built with the tool should handle additional clients without a significant impact on performance or stability. Scalability is also a function of how efficiently the client uses the database server.
Products that scale well include tools that support application partitioning through the use of proprietary ORBs (for example, Dynasty and Forte), remote OLE automation or Distributed COM (PowerBuilder, Delphi, and Visual Basic), TP monitors (EncinaBuilder from Powersoft and JAM/TPI from JYACC), or CORBA-compliant distributed objects (usually accessible using DLLs). These tools can off-load some of the application processing to a standalone application server. In addition, an application server is able to funnel database requests, thus placing a lighter per-user load on the database server.
Client/server tools need to create applications that can send to and receive data from external resources other than the database server. For instance, many tools support MAPI, which makes an application message-enabled.
Client/server tools should support direct links to three-tier and n-tier technology, such as CORBA, compliant object request brokers (ORBs), OLE automation servers, or TP monitors. This gives you the ability to move to a more sophisticated client/server architecture if the need arises, such as moving a department-level application to the enterprise.
Other features you should examine are the per-seat cost of the tool per developer, support costs, training, available developer talent, and the frequency of upgrades. The per-seat cost of most tools ranges from $1000 to $75,000. Low prices don't always mean you save money. If you can build an application in half the time, it's a bargain.
Support costs vary greatly as well. Most tools make you pay for quality telephone support. These costs should be factored into the tool decision.
You also need to have access to reasonably priced quality training. Obscure tools that don't have a popular following usually don't attract a lot of third-party training organizations, and it may be tough to find someone locally who offers classes. Therefore, you have no choice but vendor-provided training, usually at a higher price.
Another issue is the development talent you have available. For example, if you have many PowerBuilder programmers available, you should figure that into your tool selection criteria as well.
You also need to consider the availability of third-party tools. Configuration management (CM) tools such as Intersolv's PVCS or another CM product should support your tool of choice. In addition, it's handy to have a CASE tool support the tool directly, letting the CASE tool share design information with the development tool. Logic Works' ERwin and Rational System's Rational Rose share design information with PowerBuilder. Some CASE tools are even starting to generate application components such as forms or data controls.
Finally, you need to consider how often the tool vendor upgrades the tool. While frequent upgrades mean new features and capabilities, they also mean new integration headaches. However, too few upgrades mean that you use a tool that doesn't keep up with the industry. You need to consider the tradeoff. Also, you should consider how you're going to obtain patches that fix bugs; these should be readily available (downloadable from the Web, FTP, CompuServe, or other electronic sources).
A worksheet such as that shown in Table 1 offers the most logical way to approach the problem of client/server development tool selection. Unfortunately, no single tool solves all application problems. If it were that easy, we would all use that particular tool and our troubles would be over. Developers need to look at the application requirements, then find a tool that offers the best fit.
For descriptions and contact information on dozens of client/server application development tools, see the 1996 DBMS Buyer's Guide and Client/Server Sourcebook. It was mailed to subscribers in April, and can be found on newsstands and in bookstores. The Buyer's Guide is also on the DBMS Web site at http://www.dbmsmag.com.