Selecting the right client/server development tool for your organization is about as difficult as selecting a puppy from a litter of 100. They all look so cute, and they all move so fast, but you can only take one with you. Okay, sometimes two.
Choosing the right tool is not only a good (and fairly obvious) idea, it can make or break a project. For instance, tools that can't scale won't do much good with a client/server development project that needs to support 1,000 users or more. Also, tools that can't create applications that meet performance expectations will drive users away from the application shortly after deployment. Finally, tools that are not supported by other tools and object libraries put the responsibility on you to build external links to CASE, source-code control, and testing tools. There is a lot on the line.
So how do you select the proper tool? Most developers that I've spoken with could simply toss DBMS magazine up in the air and select the tool on the page that's face up when it lands. They all seem so much the same. Today, more than ever, it is critical that we understand not only what tools can do what, but also the reasoning that drives them.
This special-focus issue was designed to help client/server and Internet/Intranet developers and application architects understand the complex world of database application development tools. Included in the issue you will find four standalone reviews of new and enhanced versions of industry leaders: Borland Delphi, Microsoft Visual Basic, Oracle Developer/2000, and Powersoft PowerBuilder. Of course, the world doesn't depend on four products alone, which is why you will also find a roundup article by Robin Schumacher that paints a broader picture of what the representative tools on the market are (including but not limited to those already reviewed) for desktop, enterprise, and Net application development. Finally, I have provided a worksheet (HTML version or Excel Spreadsheet Version) for you to use when it comes time for you to evaluate the tools yourself.
Before looking at the tools themselves, however, it is important to learn how to categorize tools and understand each feature, breaking tools down to their component parts to see beyond the guerrilla marketing that drives the tool market today. Such is the intent of this article.
All tools provide some sort of programming language, allowing developers to customize the application's behavior. What's more, most tools support the object-oriented development model in some way, shape, or form. Applications are the byproducts of tools and, as such, perform the same rudimentary functions including interacting with the user, performing general application processing, and communicating, when needed, with resource servers (typically a database server). Tools need to translate user input into a language that the database can understand, and they then must process the response sets that return from the database.
Today, with multitiered client/server development in vogue, tools are able to communicate with middle tiers such as TP monitors and Object Request Brokers (ORBs) for distributed objects. They can even create proprietary objects allowing the developer to scale by partitioning the objects among any number of servers. These are application partitioning tools.
A tool's value for developers lies in its ability to handle most of the complex low-level activities behind the scenes. Unlike general-purpose programming languages such as Cobol or C++ (where developers must interact directly with APIs and the operating system), advanced tools, such as specialized client/server development tools, hide the gory details from the developer. This means that developers can build applications quickly, supporting rapid application development (RAD) and prototyping.
You can define 3GL tools as traditional, general-purpose programming languages such as C++, Pascal, Cobol, and FORTRAN. The best examples in the client/server market are Microsoft Visual C++, Borland C++, Symantec C++, and Borland Object Pascal. These general-purpose tools are not built specifically for database applications, but they usually include libraries for database functionality. They have advanced considerably in the last few years; however, 3GL tools are still more primitive than their specialized-tool cousins. Developers must deal with memory models, operating system functions, and even I/O directly from the programming language. Although the trend has been to move the developer away from the primitives through the use of interface painters, database engines, and advanced object libraries, developers will find that these tools are a bit more challenging to learn and use. However, because 3GL tools tend to use true compilers to produce efficient executables, there is a performance advantage.
Specialized tools are "specialized" because they are built for the specific purpose of creating client/server database applications. Today, specialized tools are household words -- PowerBuilder, Delphi, and Visual Basic. Specialized tools give developers everything they need to design, build, and deploy an application. They also provide high-level (mostly 4GL or visual development) programming languages, an IDE, debugger, and a library of objects that developer may use in an application. These tools are preferred for building client/server applications because of the speed at which developers can build the application. However, because most specialized tools employ interpreters and not compilers, you lose some performance. Even this long-standing distinction is slowly dissolving as 4GL tools such as PowerBuilder and Visual Basic gain true native code compilers.
Multiplatform tools (also known as cross-platform tools) are very similar to specialized tools but are able to deploy a single application to any number of platforms. The value of using multiplatform tools is that developers are able to deploy applications to organizations that have a hodgepodge of client platforms. Examples of multiplatform tools are JAM 7 from JYACC Corp., Unify from Unify Corp., and Uniface from Compuware Corp.
Cross-platform developers must grapple with issues including GUI differences such as the presence or absence of screen controls, variable operating system services and interfaces, and the availability of support layers such as OLE, ODBC, or things such as the Windows Help engine. Web browsers gloss over some operating system differences but introduce new kinds of differences when browsers don't support the same feature sets.
Smalltalk tools are in a category of their own. They take a different approach to application development, using an "objects and nothing but objects" approach. Smalltalk tools even treat relational databases as Smalltalk objects by using a sophisticated wrapping mechanism. Examples of Smalltalk tools are Object Studio from VMark Software Inc., Visual Age for Smalltalk from IBM Corp., and Visual Smalltalk Enterprise and Visual Works from ParcPlace-Digitalk Inc.
File-oriented and desktop database tools are a holdover from the now-aging Xbase tools and include products such as Microsoft Visual FoxPro and Access, Lotus Approach, and Borland Visual dBase. File-oriented databases are designed to use databases that exist in files on local or shared disks. Because the files are not true database servers, the database processing must take place in the tool and in the applications they produce. Most file-oriented database tools have mechanisms to move to the client/server model by providing database connection features from within the tools. Microsoft FoxPro, for example, even has a method to "upsize" an application, using the Upsizing Wizard to migration the file-based data to a database server. Also, by supporting ODBC access to RDBMSs in addition to their own built-in database management services, the data access distinctions between these desktop tools and specialized client/server tools such as PowerBuilder start to become a little fuzzier.
Reporting and OLAP tools, although they are not designed to create true general-purpose applications, do enable developers to create specialized analytical applications for the purpose of retrieving and processing data. SQL report writers let developers visually design reports and generate the SQL required to talk to the database. Examples of reporting tools include Report Smith from Borland and Crystal Report from Seagate Software. OLAP tools are the breed of reporting tools designed to let users and developers slice and dice their way through data warehouses, making sense of hordes of data. PowerPlay from Cognos is an example of an OLAP tool.
Code generators work like specialized tools, but they generate 3GL code for traditional compilers instead of providing their own proprietary application deployment mechanisms. An example of a code generator tool is ProtoGen from Protosoft.
CASE tools enable developers and application architects to design and deploy both applications and databases. They employ sophisticated diagramming subsystems, allowing developers and application architects to understand the system at a logical level, before generating both application objects and a database schema. CASE tools were considered highbrow just a few years ago, but many tool vendors are now joined at the hip with a CASE product. The walls between modeling and application construction have been tumbling. Two examples of modeling tools that generate applications for Visual Basic, PowerBuilder, and other development tools are Rational Software's Rational Rose and Logic Works Erwin.
Application partitioning tools, such as IBI's Cactus, Fortés Forté, and Dynasty's Dynasty, let developers create a logical version of an application and then partition the runtime objects into any number of available servers. Unlike the early specialized client/server development tools, which almost always use the two-tier, fat-client, client/server model, application partitioning tools use the n-tier model, allowing developers to run application objects on any number of servers or clients. They use proprietary object request broker (ORB) mechanisms and messaging mechanisms allowing the objects to share information.
Finally, Web development is the newest category of tools. Web development tools are really new versions of the tool types just mentioned, except that they are able to generate applications for use on the Internet or Intranets. To do so, Web tools use enabling technology such as HTML, CGI, NSAPI, ISAPI, Java, and ActiveX. Examples of tools specifically for Web development are Microsoft Visual J++ (see Figure 1) and Symantec Café Pro. Examples of tools that let developers build both client/server and Web applications are Unify and Uniface. However, there are many other examples, and the list is growing rapidly. The key point is that tools born in the Web generation build applications that run in Web browsers, while veteran client/server tools build their own interfaces and the applications are deployed as executables and usually with some support files.
The database access layer acts as an intermediary between the target database and the tool -- and the application, after deployment. The database access layer handles all of the low-level database calls for the tool. This layer could be database-independent and able to communicate with any number of databases on the market such as Oracle, Sybase, and Informix. Typically, this means that the tool must know how to load and unload drivers required to access the target databases.
The database access layer lets the tool get at the data in a few different ways. First, you can access the data as native application objects. Just by manipulating objects (changing properties and invoking methods), you also manipulate the data. All Smalltalk tools work this way, and so do some specialized tools such as Visual Basic's Data Access Objects (DAO). Second, you can access the data as a traditional relational schema. This lets you work with tables, columns, rows, and relations -- and not objects. Most developers with relational database design knowledge find this a more natural way to access information. Finally, you can access the data using its native driver interface through the access layer or by simply bypassing the database access layer (middleware) and going directly to the native database API. The value of this approach is that it can invoke services that you may not otherwise be able to invoke, such as stored procedures.
The repository layer is really just another level of abstraction above the database layer. Although some tools such as PowerBuilder, Uniface, and Oracle Developer/2000 use sophisticated repositories, a few tools such as Delphi and Visual Basic do not. (Visual Basic 5.0, however, will include a repository.) The scope and capacity of repositories vary greatly from tool to tool.
The repository layer lets you store information about the data in the database, such as a business rule that may apply to a particular database attribute, or even a color or a font for a database attribute that's to be used throughout an application. A repository can even define behavior, such as an event that occurs when a row is added to a table. This means that they work similarly to database triggers and stored procedures. Some tools, such as JAM 7, use a repository to store interface objects. Some repositories can store and process application objects and can even define security parameters for an application. Repositories may exist with the client, or they may exist with the target database, allowing the repository to be more easily shared with other developers.
In many cases, the repositories provide some of the object-oriented aspects of the tool. Because data element attributes are shared throughout the application, simply changing the attribute in the repository automatically changes that attribute throughout the entire application, including all affected objects. You can also define rules and behavior in the same way.
As mentioned already, the interface design layer is another subsystem of the tool that actually creates the screens, windows, and menus with which the user can interact. Although they differ greatly from tool to tool, interface design layers all seem to provide a palette or a form from which you can work, as well as a set of controls that you can drag onto the form. Testing functions are generally available to help you see how the interface reacts first hand. You may modify the properties of these controls through properties windows and even add code to define behavior. For instance, the properties feature can control what happens when the OK button is pressed or when the user selects a row in a data window.
The programming layer is the subsystem of the tool that lets you customize the application behavior through the use of a programming language. Most specialized tools today are event-driven, meaning that they depend on interaction with the user to trigger events such as fetching data from the database or printing a report. Typically, developers place the code behind the controls using code editors that are accessible from the interface layer. The type of code varies from tool to tool. For example, PowerBuilder uses PowerScript, a Basic-like 4GL (see Figure 3), and Visual Basic uses VBA (Visual Basic for Applications), an enhanced version of Basic. Some tools use traditional 3GLs, such as Optima++, which uses C++, and Delphi, which uses Object Pascal. Beyond the code editor, this layer also provides code-level debugging capabilities.
The deployment layer gives you the means by which to translate the application into something that the client can execute. Typically this means that the tool can create pcode and provide a runtime interpreter, both of which exist in the client in order to enable the application to run. Today, however, we are moving away from interpreters to true compilers that enable the application to run as a native executable. The advantages of using true compilers are performance and efficient use of resources. The use of a true compiler was one of the features that set tools such as Delphi apart from the rest of the client/server tool crowd and propelled their success in a rather crowded tool market. Many specialized tools, including PowerBuilder and Visual Basic, are already moving to true compilers. The deployment layer is also responsible for delivering the correct database access layer. In some instances, as is the case with application partitioning tools, the deployment layer is also responsible for generating application objects for use on the application and database servers. Forté and Dynasty are good examples of such products.
