In recent years the two-tier client/server model was reevaluated and a new concept built on scalability and maintainability was born: the n-tier application development paradigm.

Leveraged by Internet popularization and the consequent growth of Web data-driven applications, the multitier model uses thin, pure, interface clients, middle-tier business objects installed on application/transaction servers, and database objects on RDBMS.

The multitier model is definitely more effective: more distributed, encapsulated, and generic. However, client/server development is very mature, offering well-known tested technologies, tools, and methodologies that work closely to produce applications rapidly. The introduction of the n-tier model delays the application's production line because the programming team must learn several new technologies and methods to write high-quality applications.

One of the tools heavily adopted by PowerBuilder programmers using the client/server development model is PFC, a class library provided by Sybase to help accelerate development and enforce standardization. PFC acts as a base library to be customized and extended, and many companies have used it in that way. Since PFC isn't compatible with n-tier development, it's been abandoned by many programmers, resulting in losses of investments in education, productivity, and standardization.

However, with some changes, PFC can be improved to support integration with Jaguar CTS or MTS in a true n-tier model. Additionally, the framework can be extended to support rapid development of Web applications. I'll show you how to accomplish this.

Defining Business Rules
In the client/server model, business rules were usually implemented in database objects, such as triggers and stored procedures. One major problem with this approach is DBMS dependency. When moving to the n-tier approach, these rules must be implemented in distributed nonvisual objects. Maybe it's the biggest change because back-end programmers must now write objects.

Another issue is related to maintenance. If programmers are free to write rules, each object may have a different interface. So a way to enforce standards must be provided. We could use inheritance, providing common ancestors for business objects. Although most transaction servers don't support inheritance in component interfaces, the objects' implementation in PowerBuilder can use it.

To leverage existing knowledge when writing business rules, I'll provide an interface similar to the DBMS trigger concept. It's the n_cst_table object, a PB nonvisual object that provides a common ancestor for update validation:

n_cst_table
Boolean of_preinsert()
Boolean of_preupdate()
Boolean of_predelete()
Boolean of_postinsert()
Boolean of_postupdate()
Boolean of_postdelete()
Boolean of_setdata(data)

This object should be extended and implemented to provide update validation for each updatable table in the database model. To enforce standards, I suggest the naming convention n_tbl_tablename for these objects (see Figure 1).

Developing Windows Applications
PFC provides a set of powerful services that can be used to build rich Win32 applications. However, there are no user-interface templates that enforce standards and provide easy development. If we let UI programmers design all interfaces from scratch, we run the risk of getting completely inconsistent interfaces among applications, sometimes in the same application. Moreover, we want to minimize coding and maximize productivity.

To do this, we have to provide a set of windows ancestor objects inherited from PFC general-purpose windows (w_master, w_sheet, w_response, etc.) that implement the most common user interfaces using PFC services and objects.

One requirement should be that UI programmers need only supply DataWindow objects in the right u_dw controls or n_ds objects to get a fully functional interface, according to preestablished standards.

First, we have to decide if our applications will fit in MDI, SDI, or Explorer-like models. For each model one different set of templates will be needed. For the purpose of this article, I'll assume that an MDI model will be used. One possible list of these windows ancestor objects may include:

• w_form: A generic window that comprises a simple, single-row input form
• w_grid: A generic multiple-row input interface
• w_masterdetail: A generic master/detail interface with detail input support
• w_tabform: A generic window for updating multiple dependent tables or a table with many columns using a u_tab control
• w_report: A generic window for previewing, exporting, and printing reports

All of these interface templates should be integrated with an ancestor menu object whose descendant will be associated with a PFC window object w_frame descendant. This menu object should have action-related items for each interface. Providing ancestor user-interface templates will leverage productivity, letting UI programmers focus on the design of the DataWindow objects that represent data.

Will UI programmers have to call business rule objects to validate data? The answer is no. This PFC extension must provide a way to automatically trigger these objects. Why? Because in the client/server model business rules were implemented in triggers that were automatically called, without programmers' intervention. We want to be sure that rules will really be triggered independently of an individual programmer's discipline.

Earlier I suggested that business rule objects should follow a naming convention. This is more than a suggestion, it's a need. It's possible to implement an object, say n_cst_triggerrules, that analyzes DataWindow buffers to discover what data columns have changed and what table will be affected by those changes. Using table name information, we can instantiate the right descendant business rule object because its name follows a convention.

We can also collect the data and modification information for that row and automatically fill the instantiated object. Afterward we have to trigger the right method based on modification type (insert, update, delete) and moment (pre, post). Since object interfaces are standard, each object has a set of well-known methods that are used for validation, which allows the automatic triggering of business rules when users update application DataWindows.

Clearly, since business rule objects will be installed in a transaction server, we have to perform all data updates and analysis there (see Figure 2). As a result, we have to implement and deploy other infrastructure objects for the sake of synchronizing client DataWindow changes, using GetChanges()/SetChanges() methods, and controlling transactions through SetComplete() and SetAbort(). Isolating data access in a middle-tier server also has the benefit of facilitating application support because no DBMS client, ODBC, or Data Access layers will be installed-on client machines.

Developing Web Applications
The development of Web applications is a more complex task, mainly because it's not mature enough. That means there's no rule of thumb. Instead of using only PowerBuilder, programmers have to understand several other technologies and methods, such as ASP, IIS, HTML, JavaScript, PowerDynamo, DynaScript, and PowerSite. The additional time and money requirements are obvious.

Considering that our client/server programmers know PowerBuilder, what does it take to make Web application development as easy as possible for them? To do this, we have to create another class library, which simplifies the Web development process and allows programmers to customize templates to generate HTML user interfaces.

This class library should have the same requirement as the PFC extension for Windows application development: Web UI programmers should only specify DataWindow objects to get fully functional HTML interfaces. Taking advantage of Windows development programmers' knowledge, our class library can provide nvos that resemble Win32 objects but generate HTML behind the scenes. A list may include:

• n_cst_webbutton: Implements an HTML action button
• n_cst_webdw: Generates a Web DataWindow using Datawindow.Data.HTML property
• n_cst_weblayer: Provides layers for fixed positioning and z-order of objects
• n_cst_webtab: Provides an HTML tab implementation using overlaid layers

These objects should have properties that will be used to compose their HTML code (width, height, name, etc.) and string attributes that represent JavaScript client events. For example, the n_cst_webbutton might have an OnClick property that will be used to generate the corresponding JavaScript OnClick button event. The use of nvo properties to implement JavaScript code provides an HTML script pseudoinheritance because descendants can complement properties with more JavaScript code.

Although these objects can provide us with an increased level of productivity, it's not enough. We have to create a second level of objects that implement the interfaces. These objects - say, HTML templates - will combine the objects above to implement preestablished behavior. To enforce standardization and promote easy migration between Web and Windows interfaces, we should implement the corresponding templates that currently exist in our PFC extension for Windows development. The list may include:

• n_cst_webform: An HTML single-row data input form
• n_cst_webgrid: An HTML multirow data input form
• n_cst_webmasterdetail: An HTML master/detail interface
• n_cst_webtab: An HTML interface for updating multiple tables or a table with a large number of columns

These templates should navigate through internal objects, collect their HTML code, and compose a final HTML for presentation in the browser. Each object should execute actions and apply contexts contained in the ParamString returned by the browser. By the way, these actions and contexts should be generated by the browser through JavaScript code combined with user interaction.

Another important nvo that should be implemented is a kind of Web application manager that provides common services such as transaction control and a session object that implements persistence by the user. If the transaction server is EAServer, it will be easy to implement a session object using service objects. When using MTS, the session should be implemented through a database table or another persistent resource like a file.

Since our n_cst_webdw uses a DataStore internally to update data, it will be easy to use our previously built object to automatically trigger business rule objects. Therefore, we end up with Web and Windows applications automatically triggering the same set of business rules when users update DataWindows.

Providing Locale, Transaction Server, DBMS, and Tool Independence
If it's a requirement, DBMS independence can be accomplished easily when creating business rule objects and DataWindow objects. The only requirement is that programmers be oriented to use a subset of SQL compatible with all target DBMSs.

Tool independence means not being heavily dependent on PowerBuilder. It's also possible when developing business rule objects, since business rule programmers don't use PB's advanced features. If only instance variables, embedded SQL, and flow control are used, a migration to another tool will be easy, automated perhaps by a simple parser.

Server independence means implementing MTS- and Jaguar-compatible objects. Since both servers implement almost the same features, regardless of which one is better, taking care when designing an object interface will provide this independence. Additionally, when transaction server-specific code is necessary, the TransactionServer object Which() method, which indicates current server type, can be used to implement it.

Locale independence provides a way of developing applications with or without transaction and Web servers. Its purpose is to smooth the development process, allowing testing in an integrated debugging environment and eliminating the need for deployment to these servers during the development cycle.

To accomplish this in Windows application development, we have to create a new class library service that users can turn on or off to indicate if the application should try to create objects in the transaction server (instancing through CreateInstance/ConnectToNewObject) or should expect them in the library list (instancing through CREATE).

When developing Web applications, we have to provide a way to test generated HTML interfaces inside the PowerBuilder environment. To do this, we can use the currently available Microsoft Web browser OLE control (see Figure 3). By intercepting user navigation events in this object, we can instantiate appropriate inherited Web template objects for answering requests. After the testing phase, this set of objects can be deployed as a component, which will be created through an ASP or DynaScript page answering real browser requests.

Measuring Success
After implementing a framework, the main measure of success should be productivity. However, other issues should be considered, such as standardization. In our company we've developed a framework like the one described above (named TFC N-Tier). It's been so successful that we intend to distribute it.

When the database model is ready, user interface production is very fast. Developing business rules as objects allows us to access data in several DBMS. The creation of Web interfaces and the migration from a Windows to a Web UI are as easy as specifying DataWindow objects and other control properties. All of this is in an integrated, powerful, and well-known environment: PowerBuilder.

IT departments at some corporations will encounter a lot of resistance to developing n-tier and Web applications because it requires overall changes. Sometimes a completely new staff may be required. Using this framework, we could leverage the PowerBuilder programmers' expertise instead of abandoning it.