Remember three-tier and n-tier client/server development? Before the Web and Intranet development took the spotlight, trade presses overflowed with stories about how to make client/server scale to use three- and n-tier technology. TP monitors, application partitioning tools, and even distributed objects were the talk of the town. Guess what?
Another three- and n-tier revolution looms on the horizon. Or should I say a re-revolution, albeit a silent and gradual one? Based on my own experiences in a consulting organization, we built more three- and n-tier systems over the last two years than ever before, and we'll build a lot more in the near future. The Strategic Focus Group reports that three-tier and n-tier client/server applications will grow from 4.9 percent today to 19.7 percent in just two years. This growth is also fueling a rise in the interest and availability of three- and n-tier client/server technology such as TP monitors and distributed objects (such as CORBA and DCOM) and the tools that build applications around these technologies.
The problem with traditional n-tier is the complexity it brings to the development environment. Traditional three-tier, for example, requires a TP monitor or distributed objects. Three-tier developers build most of the application with a 3GL (such as C, C++, or Cobol) that uses the native API of the TP monitor or the IDL or ODL (Interface Definition Language or Object Definition Language) of the distributed object. Don't forget that you must build the user interface with a tool and language native to the client. You'll also have to build in database access from the middle tier using low-level database API calls. The same goes with most application partitioning tools: They, too, require more hand-coding than you would expect. It will take about twice the time and trouble to build an n-tier client/server application as it does to build in traditional two-tier. In many respects, we have to go back in time and use legacy development techniques when we build n-tier applications.
Times, as always, are changing. As we rush toward three- or n-tier client/server technology, tool vendors respond by building more "turn key" development tools that bring us the features and functions of traditional two-tier client/server development -- everything from visual development and easy-to-use scripting languages to the primitive but powerful TP monitors and distributed objects. What's more, the application partitioning (AP) tool market, once dominated by Forté Software Inc. (Oakland, Calif.) and Dynasty Technologies Inc. (Lisle, Ill.), now includes new AP tools such as Information Builders Inc.'s (IBI, New York) Cactus and Texas Instruments Inc.'s (Plano, Texas) Performer.
Let's look at this new trend by taking the cook's tour through two new tools. I'll look at Cactus, a new application partitioning tool, and Prolifics (the tool) from Prolifics (owned by JYACC Corp., New York), a new version of JAM/Tpi that makes TP monitor application development quick and easy.
What three-tier and n-tier client/server brings to the table is the ability to do two things that two-tier client/server can't do: funnel database connections and partition the application processing load among many servers. TP monitors are the best at database funneling, because they are able to use only a handful of database connections while supporting thousands of clients. TP monitors are also great at load balancing and recovery from system failures. Application partitioning tools, TP monitors, and distributed objects can all spread the processing load among many different machines (hence, n-tier), supporting an almost unlimited number of users and processing loads.
Cactus, like Forté and Dynasty, uses a proprietary ORB mechanism. This means that Cactus moves proprietary code to the application servers behind the scenes as the developer partitions the application. Multiplatform p-code interpreters that exist on all 35 supported platforms can convert the code into native system calls. Cactus can deploy to most Unix servers, minicomputers, and even mainframes. (See Figure 1.) You can repartition the application at any time to balance the load, create redundant servers, or process some objects closer to the data or interface. You drive Cactus through an object-based visual development environment using a common 4GL language.
Cactus is also component-based, providing many VBX, OLE automation, and ActiveX controls. You may snap these components into their Cactus application or use third-party components. You may also integrate Cactus applications using traditional two-tier client/server tools -- including PowerBuilder and Visual Basic -- as ActiveX controls. Of course, Cactus is Web-ready, which means that developers can deploy Cactus applications to the Web automatically.
I like Cactus because you can easily get to n-tier development without dealing with the details of the platforms and databases. As a Cactus developer, you simply define the business functionality at a high level on a single computer. You can test the application there to ensure that everything works correctly, and you can even hook your application up to any number of databases. Remember, IBI's core business is database middleware.
The Cactus Workbench is where you build the application. Cactus Workbench includes a front-end interface that provides access to all of the tools you need to build the application through a set of iconic tool bars, push buttons, and menus. The tool components exist inside the workbench, categorized as database access, business logic, and presentations.
Components of the Cactus development environment include the Application Manager, the Partitioning Manager, and the Object Browser. The Application Manager provides an integrated application repository that lets you manage data access, business logic, and presentation components before you partition them to a remote server. The Partitioning Manager gives you the ability to drag and drop locally developed objects onto different remote application servers that Cactus supports. The Object Browser gives you complete access to objects running locally or remotely, including identification of application components and other object characteristics.
Prolifics gives TP monitor developers the ability to build three-tier application server-based applications using Prolifics' Visual Server Development capabilities and Transactional Object Model (TOM). You can partition applications across servers using JetNet -- middleware that supports runtime load balancing. You can even move from two-tier to three-tier Prolifics application development using an automated conversion facility.
Because Prolifics can represent TP monitor application services visually, you can build service containers using a drag-and-drop mechanism. The visual editor that comes with Prolifics provides a single editing environment to build the user interface and the application services (running in a TP Monitor) and provide access to database resources.
Once you've built the interface, you can test the application without deploying it to a TP monitor or even to a remote database server. What's more, Prolifics provides a set of wizards that lets you generate basic default applications.
The TOM is where the rubber meets the Prolifics road. The TOM can encapsulate the code into a single class hierarchy that lets you change SQL and application logic in a single location. The changes propagate throughout the application using inheritance. TOM also uses a shared object repository, called the Visual Object Repository, that enables a team of developers to collaborate on an application.
You begin most Prolifics development projects by importing the database information from the database directly into the Visual Object Repository. Prolifics can generate default labels and text controls for the database schema. To create TP monitor-based services for the applications, simply drag and drop objects from the repository to the application screens. The TOM automatically creates the TP monitor code and SQL required to drive the application.
Prolifics is joined at the hip with BEA's Tuxedo TP monitor. Tuxedo is the most popular TP monitor in use today, and it runs on most platforms. With Prolifics, you no longer have to use the native TP monitor API to access transaction services. What's more, Prolifics developers can exploit all of the capabilities of TP monitors, including heterogeneous mainframe access, reliable queuing, distributed transactions using two-phase commit, and data-dependent request routing.
The availability of easy-to-use tools that support n-tier could change all that. Cactus joins other application partitioning tools on the fast-crowding market, including Forté and Dynasty. Neither Forté nor Dynasty set the world on fire, but they have dropped their prices and increased functionality in the last few years. They'll have to triple the size of their application base before I will recommend them for n-tier development; remember, they are proprietary at their core. However, they are still evolving.
What I like about Cactus is that it's being developed by a middleware company. IBI's EDA/SQL gives you the ability to link to any number of databases running on any number of platforms. IBI can leverage this knowledge with Cactus and could be the differentiating factor that makes Cactus relevant in the enterprise. Application partitioning products need to solve the glue problem before they can solve the multiplatform deployment problem. Cactus already solved the glue problem.
Prolifics seems to fill a growing need to leverage the power of TP monitors with easy-to-use RAD-like development tools. TP monitors are the best-kept secrets of application architects. We just need to take the complexity out of TP monitor-driven client/server development to make them practical. Prolifics does that.
As we face the year 2000 problem, Web TV, and network computing, we'll also face the challenge of moving traditional applications to n-tier client/server and new applications that need n-tier. Will you be ready? A better question might be, will the tool vendors be ready?
