Will your application development last like the Rolling Stones or crash and burn like Milli Vanilli?
The client/server application development tool market is similar to the music industry. What's a hit today probably won't be in a month. The question is, will your next client/server development tool have the staying power of the Rolling Stones or will you end up with another Milli Vanilli?
The fact is, most client/server development projects fail before the working applications make it to end users. Why? The reasons can include unrealistic expectations of client/server technology, the skill levels of the designers and developers, as well as huge unexpected cost overruns. Many of these problems are traceable to bad development tool decisions, or not using the right tool for the job.
So how do you know how to select the right tool? The answer lies in an understanding of the industry. Client/server architects, application designers, and developers need to take the time to understand the complex and ever-changing world of client/server development tools. They need to know how to select the best tool for the job by moving from the requirements to the technology, and never from the technology to the requirements. They need to know how to categorize tools and sift through the market hype to unveil the true capabilities of the product. Finally, they need to know how to measure the success or failure of a tool decision in real dollars.
Let's see if I can make sense of today's state-of-the-art client/server application development tools. In this article, I look at the capabilities of such tools, tool categories, the cost of the tools (both hidden and obvious), and many examples of the popular tools available today.
Client/server application development tools are development environments, compilers, or even frameworks for building client/server applications. As a quick review, client/server applications have a few basic characteristics: They usually run on the client and interface with the user. They usually use the native GUI (Windows 3.11, Windows 95, Windows NT, Motif, MacOS, and so on). They provide an integrated development environment in which the developer can piece together an application using a screen painter, object browser, and code editor. They provide built-in links to various databases (remote and local). They provide some sort of programming language. And they are almost always object-oriented in some way, shape, or form, and provide application distribution capabilities.
The client/server applications built by these tools interact with the users, perform general application processing, and interact with the database when the application requires data. The application translates input from the user into a database request that communicates with the database using the proper query language and dialect. They use native database drivers or ODBC. ODBC provides the least common denominator for database access. The database may be a file local to the client, or a remote database server that serves hundreds of users. Sometimes a tool may communicate with a middle tier, such as a TP monitor or distributed object. However, the basic concepts are the same.
All of this happens behind the scenes, out of the end user's sight, and, in many cases, out of the developer's sight. The ability to remove the developer and the end user from the underlying complexities of application development, middleware APIs, network communications, and database processing is the real value of these tools. This enables developers to create powerful client/server applications with a minimal amount of work.
Beyond general characteristics, the similarities end. Most tools have their own proprietary approach to creating and deploying client/server applications. For instance, most client/server development tools (including Powersoft's PowerBuilder, Centura Software's SQLWindows [formerly Gupta Corp.], and Microsoft's Visual Basic) use their own proprietary development languages, as well as their own proprietary object libraries. In addition, each tool has its own special approach to database connectivity, GUI painting, and application execution.
The best way to understand the mass of available client/server development tools is to learn how to place tools in one of several basic categories, including specialized tools, file-oriented database tools, cross-platform tools, application partitioning tools, Smalltalk tools, 3GL compilers, and frameworks. Of course, some tools fit into several different categories (for example, specialized tools that provide application partitioning capabilities, cross-platform tools that use 3GL compilers, file-oriented database tools with client/server options, and so on). As time goes on and tools provide new features, this will become more apparent. Having said that, it's still a useful exercise to categorize client/server application development tools, and thus make it easier to quickly locate the tool that is the perfect fit for your next client/server development project. Moreover, it's sometimes possible to provide subcategories to further define the capabilities of a class of tools.
Specialized tools are highly proprietary application development environments that provide developers with everything they need to design, create, and deploy client/server applications. For instance, all specialized client/server application development tools provide: rapid application development (RAD) capabilities; easy-to-use 4GLs; built-in connections to popular databases; integrated development environments (IDEs), including screen painters; varying adherence to the object-oriented model; object libraries; and the ability to use components. In addition, most of the specialized tools available today use the traditional (and simple) two-tier client/server model. This category represents the majority of popular client/server development tools on the market today, including PowerBuilder, SQLWindows/Centura, Visual Basic, Symantec's Enterprise Developer, Oracle's Designer/2000 and Power Objects, and many others.
RAD is the reason many of these tools took off in the early 1990s. Generally speaking, RAD enables a developer to build an application quickly by designing the user interface first in a visual development environment, and then placing the code and data behind the interface to provide behavior and create an application. Therefore, it's possible to create many simple applications right before the eyes of the end user, because the developer is removed from the complexities of a 3GL, a compiler, a database, middleware, and the network layer.
Although RAD is popular among MIS shops that create many simple applications (such as order-entry applications), many are finding that complex applications, despite the RAD capabilities of today's tools, require a rigorous design and testing effort. Today, many organizations still categorize specialized tools as RAD tools, hoping that these specialized tools will become the magic bullets to save them from application backlogs.
All specialized development tools provide some sort of IDE. This powerful feature lets developers create the database, design the screens, menus, and reports, add program code, and compile the application from a single interface. This provides the developer with a consistent look-and-feel throughout the application development process. Visual Basic, SQLWindows, and PowerBuilder were the first specialized tools to offer a modern IDE for Windows development. Today, most tools mentioned in this article provide IDEs.
Specialized tools usually provide some sort of repository that contains all sorts of information about an application, including attributes of data elements (color, integrity checks, fonts, and so on), application objects, screen attributes, components, and even links with other repositories. PowerBuilder's extended attributes (PowerBuilder's repository), for example, let developers store shared application and database information. A developer need only define a repository entry once, and it's automatically propagated to the other portions of the application that use it. For instance, a PowerBuilder developer can define a numeric data element to display on the screen in red if it's a negative value. Each time the data element is used in a screen, it carries the attributes from the repository with it. Repositories also provide reuse infrastructure for application development tools, including the means of reusing application objects in a team development environment.
Built-in database connectivity provides great value for developers. Rather than use cryptic middleware APIs such as native database APIs and ODBC, the development tool handles database connectivity and management on behalf of the developer. (In other words, the tool handles all of the database access for you, such as reading the schema directly into the tool's native repository. If you are developing a client/server application in a tool that's not database aware, you'll have to create the code to handle access to the database using cryptic APIs.) Most specialized tools connect to popular database servers such as Oracle, Sybase, and Informix. However, using the open ODBC interface, these tools can connect to still more databases. In addition, many specialized tools provide tiny, single-user database servers that run locally on the client. This enables a developer to develop an application before purchasing a true remote database server.
Specialized tools not only connect to databases, but provide developers with the means to create or alter physical database schemas -- tasks that normally require a DBA tool. A few of these tools, including Enterprise Developer and PowerBuilder, provide sophisticated interfaces to physical database structures. Both of these tools offer CASE-like interfaces that let developers graphically create and modify tables, as well as link them together.
Most specialized tools adhere, at least in part, to the object-oriented development model. Although a detailed discussion of object-oriented development is out of the scope of this article (for example, classes, objects, encapsulation, polymorphism, inheritance, multiple inheritance, and so on), it's important to mention the basic capabilities.
The object-oriented model allows developers to create applications from definable parts known as objects. Each object can encapsulate both data and methods, and each object can take advantage of the data and methods in other objects through the concept of inheritance. Inheritance means that an object can absorb the capabilities of another object, using what it needs and discarding what it does not need. For example, when creating a custom DataWindow inside PowerBuilder, a developer usually inherits from an existing DataWindow that could already exist in another portion of the application, or, could exist in a object library that came with the tool. Therefore, the developer does not have to create a DataWindow from scratch, but can use (or reuse) existing objects and thus save development time. The idea is to program from the generic to the specific, reusing as much of the existing application or object library as possible.
Object libraries build on the concept of inheritance by offering developers hundreds of pre-built objects for use inside new applications. Developers can find everything from basic GUI controls to database entry forms inside these libraries, and it's just a matter of locating the right objects to fit the particular requirements of an application. If you can't find the right objects, you can look to third-party object libraries that exist for specific tools, or build the object from the ground up without the benefit of inheritance. For the most part, the best developers aren't those who know how the program uses the proprietary 4GL, but those who know the native object library and where to find the objects they need.
Most specialized client/server development tools provide their own proprietary 4GL that allows developers to define the low-level behavior of the application. These 4GLs go by strange names such as PowerBuilder's PowerScript, Visual Basic's VBA (Visual Basic for Applications), and Enterprise Developer's ScaleScript. Borland's Delphi takes a slightly different approach, using the 3GL-like Object Pascal language for low-level programming, a divergence from the high-level 4GLs found in other tools.
Generally speaking, these 4GLs provide developers with the ability to make the application do exactly what it is supposed to do. They use familiar programming statements such as if, then, else, for, while, and so on. However, the idea is to do as much as possible visually with the tools, and avoid the time-consuming task of writing code. These tools deploy applications to clients by providing runtime environments, which include p-code interpreters and DLLs for database connections. Unlike compilers, which produce native executables, p-code-based applications are somewhat slower. A few innovative specialized tools such as Delphi can deploy applications as speedy native executables.
The weakness of using 4GLs is the fact that each is proprietary to a particular tool. Therefore, developers can't use portions of legacy code such as Cobol, Ada, or C. Nor is this code portable to other development environments. The lack of a standard programming language is still binding applications to tools. This could change as more tools migrate toward common shareable objects based on OLE, and, to a lesser extent, CORBA.
Most specialized tools are reasonably priced. Most popular tools run between $1500 and $3000, depending on features such as database server support. However, the real cost is in the productivity of a tool. An inexpensive tool that requires twice the development time is not at all inexpensive. This applies to a few tools I mention later in this article. Ease of use leads to productivity, which leads to fewer development hours, which leads to cheaper applications. Of course, ease of use is a relative term, and developers need to examine closely the productivity benefits of a tool before selecting it for their projects.
Today, file-oriented database tools provide many of the same features as do specialized client/server tools. However, they are built to use database files that reside locally on the client or files that reside on a shared file server. These tools not only provide an easy-to-use application development environment, including visual development and a native 4GL, they also provide a built-in relational database manager. The difference is that database processes happen within the tool or run-time application, and not at a remote database server. Even if the database physically resides on a shared network drive, the data is transmitted to the client or the network for processing.
The genesis of file-oriented database tools is found in the traditional Xbase tool of the 1980s -- tools such as dBASE, Foxbase and FoxPro, Clipper, Quick Silver, and many others. These tools brought relational database and application development power to the emerging IBM PC marketplace. As organizations sought tools that could serve more users with better performance, the specialized client/server tool movement began, and this overshadowed the existing file-oriented database tool marketplace.
Today, file-oriented database tools such as Visual FoxPro from Microsoft and Visual dBASE and Paradox from Borland are evolving to meet the needs of today's developers. (See Pete Olympia's article, "Visual Desktop Databases," page 55.) These needs include adding popular client/server development features such as support for the object-oriented development model, visual development, and access to popular database servers as an option. In fact, it's safe to say that file-oriented tools and specialized tools share more features with each new release. Fortunately, they don't share price tags. File-oriented tools cost just a few hundred dollars, far cheaper than the $1500 you'll spend for most specialized client/server development tools.
These tools, however, don't yet provide the same level of client/server application development capabilities as most popular specialized tools. The remote database connections and SQL capabilities are more of an afterthought. However, they are well suited for those who want to create a small-scale database application that can move up to client/server as requirements change. Developers can make these file-oriented applications client/server by simply adding a driver or two, and migrating the database from the database files to a full-blown database server. Popular file-oriented tools such as Visual dBASE, Visual FoxPro, and Paradox are all ready to move toward out-of-the-box client/server.
New file-oriented database tools such as Microsoft Access and Lotus Approach just hit the streets a few years ago. These "new kids on the block" provide non-technical types with the ability to create and access simple databases (local file, multiuser file, or remote database servers) with limited application development capabilities. Access, for example, uses a series of "wizards" that guides the end user through the process of creating a database, data-entry forms, and even simple applications for distribution to users. All of this without the complexities of programming.
These tools have other productivity features such as messaging capabilities for workflow applications, and the ability to provide OLE automation services. All this at around $100 a copy. The simplicity of these tools and the low price ensures their place as a development tools for simple standalone and small workgroup applications.
Cross-platform tools look and feel like specialized tools, but their applications are portable from platform to platform. This means that developers can build an application using the Windows version of the tool, then run that application under OS/2, Windows NT, Unix (many flavors), Macintosh, or any other platform that the cross-platform tool supports. Examples of popular cross-platform tools include Unify from Unify, Omnis7 from Blyth Software, Uniface from Computer Associates, C/S Elements from Neuron Data, Galaxy from Visix, JAM from JYACC, and Magic from Magic Software.
These tools are attractive because, unlike Windows-only tools such as Delphi and Visual Basic, developers can hedge their bets when considering future platform support. Moreover, they are extremely useful in organizations that employ a hodgepodge of operating systems and processors.
Cross-platform tools support multiple platforms by placing a layer between the application and the native environment. When moving from platform to platform, the developer simply swaps in a new native layer.
Each cross-platform tool supports cross-platform development in its own way. Most tools don't attempt to support the native feature of each environment, but instead provide a consistent look-and-feel across platforms. They do this by bypassing the native APIs and emulating the controls by using the graphics layer directly. C/S Elements and Uniface are examples of cross-platform tools that use emulation. Developers and tool vendors find this method of providing cross-platform development easier to understand and use. However, end users may find that applications don't provide the native look-and-feel they expect.
There are other drawbacks as well. Cross-platform tools are notoriously expensive, as much as $10,000 per tool. Cross-platform tools also charge by platform; therefore, supporting three platforms requires that you purchase three separate licenses at various costs. Moreover, by supporting so many different platforms, cross-platform tools don't seem to look or perform as well as native tools. Selecting a cross-platform tool because you may port to another platform one day could cost you thousands of dollars in development costs, tool costs, and end-user productivity. Developers should only consider cross-platform tools if there is an actual requirement to deploy on multiple platforms.
Relatively new to the tool market, true application partitioning tools provide the ultimate in scalability. These tools dynamically distribute portions of an application to as many application servers as are required to support an application processing load. The premier application partitioning tools are Forté from Forté Software and Dynasty from Dynasty Software. A few tools, such as Unify and PowerBuilder 5.0, now provide some application partitioning capabilities as well.
Both Forté and Dynasty let a developer create a logical version of an application on a single workstation. As with other specialized client/server development tools, developers create objects and add behavior to form the application. Once the application exists, developers can move portions of the application as objects to physically run on various application servers accessible by a network. All that's required is that the developer drag an object and drop it on an icon that represents an application server. In the background the application partitioning tool generates and compiles native source code locally on the application server, thus creating an executable to run on the server. The objects that execute on various servers communicate via a proprietary messaging system.
The principal benefit of application partitioning tools is scalability. Traditional two-tier tools (most of the specialized tools I mentioned previously) can't support much more than 100 users. In contrast, application partitioning tools are multi-tiered (or n-tiered) and can split the application processing among processors. This means they can share the load, and developers can create applications that are potentially able to support thousands of users. If more capacity is required, a developer need only add another application server, and partition the application again so that it's split evenly among available processors. This is known as dynamic application partitioning and load balancing.
There is a downside to application partitioning. These tools are very expensive, as much as $100,000 per developer. In addition, the mechanisms of the tool are highly proprietary. Those who want an open application partitioning solution may want to wait for the upcoming distributed OLE standards, or use available CORBA 2.0-compliant object request broker (ORB) vendors.
Smalltalk-based tools are in a category by themselves because they represent a very different method of development. They use objects and nothing but objects in a development environment that's wrapped in a sophisticated IDE. The current list of Smalltalk tools includes Object Studio from VMark Software Inc., VisualAge Team for Smalltalk from IBM, and Visual Smalltalk Enterprise and VisualWorks from ParcPlace-Digitalk Inc.
Smalltalk-based tools use the 4GL-like 20-year-old Smalltalk language, as well as an extensive object library to define an application. Inside of all Smalltalk-based environments, everything is treated as an object. You select objects from the library to build an application, then extend the capabilities of those objects through inheritance. Specialized tools only support portions of the object-oriented model. For instance, PowerBuilder provides developers with the ability to create applications using objects, but database access is still a procedural process.
Smalltalk-based development tools are considered pure object-oriented tools. This means that developers must treat variables, arrays, and even relational database tables as objects inside the Smalltalk environment. Database wrappers are part of the Smalltalk-based client/server development tools, as are an extensive object library and an object browser for locating the objects you need. If you're considering Smalltalk for client/server development, you should judge the tool on the objects that come with the tool, as well as the wrappers for external resources that you may require, such as database servers, interprocess communications, or real-time communications.
Although they are very powerful development tools, Smalltalk tools force developers into the object paradigm, and it could take awhile before they become proficient in the ways of object orientation. In addition, Smalltalk uses interpreters exclusively, thus application performance could be a problem on slower platforms. Smalltalk tools are expensive as well, with tools usually running in the thousands of dollars.
3GL compilers include C++ and Pascal compilers, such as Borland C++ and Object Pascal from Borland, Visual C++ from Microsoft, and Watcom C++ from Watcom. These are primitive tools with attractive front ends that deliver blazingly fast native executables if developers are willing to do what it takes to create an application using a 3GL.
Today's 3GL compilers are very different from command-line compilers of the past. Tools such as Borland C++ and Visual C++ provide developers with powerful IDEs to create applications and browsing class hierarchies, as well as to compile and link applications. These tools also provide database connectivity features, albeit from cryptic APIs embedded in the code.
C++ compilers are only as good as the available application objects, and the inclusion of frameworks with the tools provides developers with base sets of objects for GUI application development. For example, Borland C++ includes a GUI framework known as the Object Windows Library (OWL), and Visual C++ provides Microsoft Foundation Classes (MFCs). Most compilers with native frameworks cost approximately $500.
If you can't find what you need in the classes that come with the compiler, third-party frameworks provide additional capabilities. For instance, dbTools.h++ from Rogue Wave Software provides C++ developers with a wide range of database server connectivity objects. The developer need only learn the framework and where to hook up the application.
Portable frameworks (such as XVT, Zinc, zApp, and Galaxy) make C++ code more portable, because they are native versions of the frameworks for many different platforms. Developers write an application to a proprietary API that has versions of libraries existing on several platforms. Thus, the application is removed from the underlying native OS layers. Frameworks such as OWL and MFCs are native to Windows (OWL is supposed to be portable, but I have not seen it yet). Therefore, those particular frameworks tie your application to a single environment.
There could be a common technology that finally binds some of these tools together. This technology is known as application components. Application components, simply put, let developers place standard components or objects inside of applications to take on some of the application processing for the application. For instance, there is no need to create your own calendar component when you can purchase it from a third party and drop it directly into your application. However, the tools need to know how to use such components. Today, most do.
Component technology is limited to two very different camps: OLE and OpenDoc. OLE (and its OCX incarnation)is available today and allows developers to place OCX components inside applications using tools that are OLE-aware. OCXs are language independent. Therefore, you can use OCXs created with Microsoft Visual C++ or even Visual Basic inside other OLE-aware tools such as Borland's Delphi, PowerBuilder, or Oracle's Power Objects. The tools know how to interact with the components by using a standard interface that does not change from tool to tool. This enables developers to mix and match components inside applications and can save hundreds of hours in development time. Currently, OLE and OCX support is limited to Microsoft operating systems (Windows 3.11, 95, and NT).
OpenDoc is a component technology-based CORBA and is functionally equivalent to OLE. OpenDoc supports Microsoft and non-Microsoft operating systems such as OS/2, Unix, and Macintosh. However, OpenDoc is far behind OLE in popular tool support.
So what are the current trends of client/server application development tools? In short, you're going to see more application partitioning capabilities, links to distributed objects such as Microsoft Network OLE and CORBA, more components, and better deployment mechanisms.
With the popularity of true application partitioning products such as Dynasty and Forté, tool vendors see the need to provide products that scale to the enterprise through partitioning. This is apparent in new versions of existing products such as PowerBuilder and Unify. PowerBuilder, with its 5.0 release, provides developers with the ability to distribute non-visual objects to other processors. Unify now provides similar capabilities.
Tools such as Delphi, PowerBuilder, and Visual Basic are ready for Network OLE, when it becomes available. Network OLE will have common distributed object capabilities built into the operating system. Distributed object capabilities will serve as both a standard application partitioning mechanism that allows the sharing of object servers among different development tools, as well as a common middleware infrastructure. Today's tools already allow developers to build OLE automation servers, both in-process and out-of-process. Distributed OLE is clearly the next step.
Application omponents will also continue to be a factor. Most Windows-based tools support OCXs, and developers can mix and match application components. Today, components that support ODBC make up the only standards vendors can agree upon.
Although CORBA-compliant distributed objects have not made the same impact on client/server development as OLE, a few innovative tool vendors support connections to CORBA objects. PowerBuilder 5.0, for instance, can invoke services on remote CORBA-compliant ORBs directly from the tool. Other tools provide similar features by loading DLLs.
Tool vendors will continue to seek better deployment mechanisms. Delphi has one of the better application distribution capabilities in the business, using a true native compiler. This frees the developer from the bonds of slower, less efficient, p-code interpreters. Other tool vendors will follow suit. PowerBuilder 5.0, for instance, now deploys applications closer to native, and SQLWindows combines C++ code generation and a compiler to provide native code execution capabilities.
Every year client/server application development tools get better. Still, there is much work to be done to improve the development capabilities, standards, and deployment. Future improvements will make the tool market less confusing, yet every month four new products hit the streets and the job of selecting the right tool is becoming a project unto itself.
(For a comprehensive list of application development tools, see the product chart on page 76.)