Now that you have taken the plunge, let me tell you the two most important things that go in to developing distributed applications-

1. A good, industrial strength development tool, and
2. Strategy

While PowerBuilder 6.x sufficiently provides for the first requirement, the real challenge lies in coming up with a solid design and development strategy. As someone stated so correctly in a discussion on the PowerBuilder forums - 'You can't RAD the middle tier'. You bet. Distributed applications require upfront planning. This section focuses on some of the important issues that should be considered before starting development.

Choosing the target Server and Client

Believe it or not, this foremost issue is probably the most muddled one. With PowerBuilder 6.5 you have a lot of choice as far the type of Server and Client you want. Take a look at some of the possibilities-

Each approach has it's merits and drawbacks. I hope to address this issue in detail in a future article. For now, lets take the simplest approach of a PowerBuilder application accessing a DPB server. This is the most common architecture for corporate applications and will also help us understand the basics of using PowerBuilder in a distributed computing environment. Also this approach doesn't require you to know any other technology than just PowerBuilder.

Note: An important reason to used distributed computing is that you want to access the same logic from different types of client applications. In fact, in my next article in this series we'll see how to access the logic that we build here from a browser using Web.PB. We'll keep that in mind while we are planning our application.

So, what we are going to do is build a Employee maintenance application that-

1. Splits the application logic into client and server side components
2. Keeps the business logic on a Distributed PowerBuilder server application
3. Keeps the presentation logic on the PowerBuilder client application

And before you accuse me of using vague terms, let me say that the very next thing that we are going to do is decide what will constitute the business logic and the presentation logic.

Partitioning the Application

Before we get to the partitioning part, it helps to know what is it that we are trying to split! Let's decide on what we want our application to do. Let's say the screen has to look something like this.

1. The User should be able to retrieve a list of employees in the left hand side datawindow by clicking on the 'Refresh' button.
2. Selecting an employee on the list should bring up the corresponding record in the right hand side datawindow for editing.
3. The user should be able to add new employees, update information about existing employees and delete existing employees. The 'Add', 'Delete' and  'Save' buttons will be provided for this purpose.
4. The application needs to make sure that the salary of an employee should be between a specified range. Okay, I know that this is an absurd business rule, and no company in it's right mind would impose such a rule flatly across all employees. But I honestly could not think of a good business rule since our example is so simple. So please bear with me.

This seems to be a simple, everyday PowerBuilder chore. And how do we do it in a typical 2-tiered PowerBuilder application? We would probably -

• Create a new window
• Create the grid and freeform datawindow objects.
• Paste a couple of datawindows on the Window and assign them the correct datawindow objects.
• Tie up the freeform datawindow to the selection in the grid datawindow.
• Code the Retrieve(), InsertRow(), DeleteRow() and Update() for the Refresh, Add, Delete and Save buttons respectively.
• Before saving a record we would make sure that the salary has been specified correctly.

Now, lets analyze this process and segregate the logic involved.

Presentation Logic

This handles the user interface part. It consists of the window, datawindow controls, the code to tie up the two datawindows, inserts and deletes and displaying the error message in case of an invalid salary amount.

Business Logic

This consists of the actual salary amount validation. The salary range.

Persistence Logic or Data access

This consists of the datawindow objects, the retrieve and the update. Many people like to think of it as a part of the business logic. But I like to treat it as a separate entity. This provides more clarity to the design.

So, when we talk about partitioning the application what we are saying is that the client application should handle just the presentation of data and the server application will take care of the business rules and the database access.

The Development Strategy

One of the nice things about developing distributed applications with PowerBuilder is that you can actually develop the application as a monolith and then split it across two tiers. If you are careful with how you build it, you can split it with minimal change to the code. Since we have figured out the logic we want to put on the server it's a good idea to encapsulate this logic into a NVO(Custom Non Visual Object). Then, when we are ready to split the application, we'll place the NVO on the server.

Business Objects

NVOs like the one discussed above are also known as Business Objects. So we will develop a NVO that will encapsulate -

• Retrieval of data from the database
• Updating the changes to the database
• Logic for validating the salary amount

The presentation logic will call this NVO for fetching, updating and validating the data. We'll have to come up with a mechanism to pass the retrieved rows from the business object to the code that handles the presentation. We'll also need a mechanism of sending the changes made by the user to the business object.

Introduction

Strategy
Building the monolith
Building the DPB Server
Building the PB Client
Setting up the DPB Server
Deploying the PB Client

Points to Ponder
Where to go from here

 Download the application

What's Next?

Related Links:

Sybase's Adaptive Component Architecture Tools Perspective

Business Logic Presentation from the 1998 Powersoft User
Conference