There doesn't seem to be any doubt about it: The more software tools there are to help us design and build business applications, the more complex and time-consuming the process seems to become. Yesterday's host-based or client-server application now needs to run all over the world, with many interfaces to users and to other applications. And you have to expect to adapt to more new requirements almost overnight. Here are some of the challenges you face.

Complex data

Relational databases handle individual two-dimensional tables of business data very well, and programmers who understand how to code and optimize the relations between tables can produce a set of usable data. But it's hard for business analysts to do all the relational composition to assemble the data that they need in their business rules, and hard for the programmers to understand what the business needs are.

For example, a developer supporting a business analyst may have to ask himself: How do I construct a SQL query that joins eight or ten database tables to provide all the data needed for order processing?

Complex physical schemas

Aging databases often become more complex and inconsistent over time, reflecting the changes that result from combining applications, changes in the use of data, and a lack of naming and organizational standards. A good application needs to shield the developers who are just trying to express business logic - which is a hard enough job in its own right - from the idiosyncrasies of the physical database design.

So that developer must examine the database schema and ask: How many different names are there in my database for the Customer ID and how do I make them look the same to the analyst who is trying to code business rules?

Distributed applications

Today's applications have to support users around the world running on a wide variety of clients, with limited connectivity to the central application and its database. This introduces a host of complications for networking and communication from client to server, as well as indirect or optimistic locking requirements that make it harder to maintain data integrity in the face of many concurrent users with access to the database.

So the developer must always ask questions like: How do I program now that the user interface can't connect to the database directly?

Duplication of program logic

When you have a new task to program that looks similar to something the application already does, it's all too tempting to copy and paste an existing block of code, and then edit it to add the new behavior. The result over time is an application where many basic functions are duplicated dozens of times, resulting in code that is inconsistent and hard to maintain.

To reduce the complexity of the application, architects must address high-level questions before they let the developers start coding: How do I build an architecture so that my developers can really do each programming job once and only once?

Multiple clients

Today's users run many different kinds of devices to access data, and these require different interfaces with different capabilities. If the application logic assumes a particular user interface or client type, and even tries to control the UI directly from the business logic, then adding a new client platform can wreak havoc on the application structure.

To make sure that they do not lock themselves into a single user interface platform, developers must ask: How do I truly separate UI definition and logic from my business logic, so that I can support new client types when my business requires it?

Service Oriented Architecture

SOA is more than just a trend. To succeed in today's world, older applications have to be integrated in ways that were never imagined when the applications were first written. Adapting an older application to act as a Web service or to run other applications as Web services can be enormously difficult.

Developers must think about how their application may need to be accessed from other applications: How do I set up my application to be ready to act as a set of services when I need them?

These are the kinds of real problems that we help developers solve with the new capabilities we add to the Progress language and OpenEdge product in each new release. One of the most significant new features of our most recent major release, OpenEdge 10, is the ProDataSet. It's designed to help address all of the problem areas I outlined. It also maps to similar objects that are supported on other platforms, such as .NET and Java, which is why we identify our new object as the ProDataSet. Here are some of the ways it can help you build successful modern applications:

The ProDataSet is a manager of complex data

The business analyst who has to design and even code the logic that drives the application doesn't want to be confronted with the relational algebra that's needed to pull all the right data out of the database and make it available. The ProDataSet lets the business analyst work together with an expert in the application schema to define an object where the relations and joins are built in, and the right data is brought in from the database automatically to satisfy a request. The ProDataSet defines a set of in-memory tables, each of which can map to one or more database tables, along with a description of how those in-memory tables in turn relate to one another. In most cases, a simple top-level request tells Progress all it needs to know to bring all the right related data into the application.

Figure 1. Given just a request for Order number 26, the ProDataSet can provide the Order header and all the Order Lines and other detail for the Order as a single object

Here's the code to define the in-memory tables (called temp-tables in Progress) and the ProDataSet that relates them:

Listing 1. temp-tables in Progress

/* Source file dsOrder.i is included in procedure files that
   reference this ProDataSet and its tables. */
 
/* This table holds rows from the Order database table.
   The BEFORE-TABLE holds original values for modified rows. 
   The table names use a convention of a prefix of �e' 
   to indicate that these are tables for business entities: */
 
DEFINE TEMP-TABLE eOrder BEFORE-TABLE eOrderBefore
    FIELD OrderID AS INTEGER
    FIELD CustNum AS INTEGER
    FIELD OrderDate AS DATE
    FIELD ShipDate AS DATE
    FIELD OrderStatus AS CHARACTER
    FIELD CustName AS CHARACTER 
    FIELD OrderTotal AS DECIMAL 
    INDEX OrderID IS PRIMARY UNIQUE OrderID.
 
/* This table holds rows from the OrderLine database table: */
 
DEFINE TEMP-TABLE eOrderLine BEFORE-TABLE eOrderLineBefore
   FIELD OrderID AS INTEGER 
   FIELD Linenum AS INTEGER 
   FIELD Itemnum AS INTEGER 
   FIELD Price AS DECIMAL 
   FIELD Qty AS INTEGER 
   FIELD Discount AS INTEGER 
   FIELD ExtendedPrice AS DECIMAL 
   FIELD OrderLineStatus AS CHARACTER 
   INDEX orderline IS PRIMARY UNIQUE OrderID Linenum. 
 
/* The DATASET definition pulls these two tables together into
   a single object and defines their relationship: */
 
DEFINE DATASET dsOrder FOR eOrder,eOrderLine
        DATA-RELATION OrderLine FOR eOrder,eOrderLine
            RELATION-FIELDS (OrderID,OrderID).