Distributed computing is a relatively nascent field. People are still trying to figure out what are the best strategies and practices for building high performance distributed systems that really work. So don't be surprised if you find that even the experts seem to be giving out contradicting advice. I hope that this article has been able to show that building distributed system requires you to 'think distributed'. As you delve deeper into distributed applications you will face dilemmas and predicaments that you have never encountered before when building two tiered applications. In this section I hope to raise some important issues that many PowerBuilder developers face. In most cases there is no 'absolutely correct' answer. The solution usually involves tradeoffs and depends upon the specific problem you are trying to solve.

Should I put even trivial business logic on the server?

Does it make sense to put every piece of business logic on the middle tier? Even basic validations that are usually coded in the itemchanged event? Example - "Amount should be greater than zero" or "Quantity specified in the order must be greater than 'quantity_on_hand' in the 'product' table". From a design point of view, this is certainly desirable. But unfortunately the hardware that our applications run on is less than ideal and you have to deal with the reality of bandwidth and response time. Does it make sense to reach out all the way to the server on every itemchanged event? Probably not. So, should these trivial business rules be placed on the client? Well, if you do that then this logic won't be available to other types of clients that connect to the DPB server. Or, you might end up putting the logic in more than one place - in the DPB Server for HTML clients and additionally in the PB client application. Here are some approaches that you can consider -

1. If the DPB server application is only meant to serve PB clients and your user interface requires that you perform validations in the itemchanged event, then you can put trivial business rules on the client. But instead of coding them directly into the itemchanged event, put them into a client side business object or into a general NVO that manages all such rules. Make sure that these rules are fairly static and will not be required to be changed often.
2. Consider not validating data in the itemchanged event and only validating before the final save. These pre-save validations can be kept in the middle tier. The bandwidth wont' be concern now, since the client is going to call the server only once to perform all the validations. This approach will work well with HTML clients too because HTML clients depend upon the server for validating the data.
3. You can still consider keeping extremely basic validation like 'Amount must be greater than zero' on the client. In PowerBuilder, you can put this in the itemchanged event and in case of HTML clients you can use JavaScript.

Should I use PFC on the server?

PFC is largely a GUI framework/classlibrary. PFC was designed to provide reusable functionality to typical 2-tiered applications. It's  real benefits are leveraged in applications that have large and complex user interfaces. Hence it is not particularly well suited for developing server side, non-visual business objects, per se. Instead, consider other DPB class libraries like DFBC from Tikal and HOW OpenFrame from Riverton.

The down side of using the datawindow state functions

So, you were really impressed by how the state functions simplify data transfer across tiers. There's no doubt that the state function are really 'cool' and have greatly eased development of distributed applications using PB6.x (ask the guys who have done it with PB5.0 using cumbersome structures and strings to pass data). But the down side is that it will only work as long as you only have PowerBuilder on the client. This is a proprietary way of passing data and won't work with Visual Basic or Java clients. If you are going to have different types of clients accessing middle tier objects written in PB, you can consider the following options-

1. Take the 'least common denominator' approach and use only structures and strings to pass data.
2. Keep using state functions for PowerBuilder clients, but provide wrappers for other clients as and when the need arises. Wrappers are required for HTML clients anyway. For example you can have of_getlist() that returns a blob for PB clients, of_getlistHTML() that returns the results as HTML for browsers, and of_getlistString() that returns the result set as a tab delimited string for clients like VB and Java. Internally, of_getlistHTML and of_getlistString() call of_getlist() and then convert the blob to the appropriate format. Conversion isn't too difficult and we will explore this technique in future articles.

Error handling in a distributed application

Don't forget the two and half tier.

It's unfortunate that hype often obfuscates reality and molds the way in which people think and approach a problem. All this talk about new n-tiered architecture and technologies has distracted our attention from something that we already have that can be as effective in many situations - the 2 and 1/2 tiered architecture!! No this is not some freakish conception of a bizarre mind. What I am talking about is the ability to store logic in the database using good ol' stored procedures! Just consider the benefits-

1. Ability to change business logic quickly without changing the client application
2. Efficiently handle large and complex processes that are database intensive.
3. The logic can be accessed by any type of client
4. The database server can be scaled to handle larger loads

Isn't it uncanny that these are the very same benefits that we are trying to achieve using n-tiered computing? Moreover, the latest databases offer other powerful ways of storing logic in the database like user defined functions, object databases and Java classes. Agreed, that the database may not be the best place to store all business logic and that scaling is not as flexible as a separate middle tier, but this approach is worth considering in many situations. So, don't forget the two and half tier.

Distributed Computing: Reality Check

Finally, lets take a closer look at some of the commonly touted benefits of distributed computing and see if they can really be achieved in real life scenarios.

Hype: Better Performance
My client applications will run faster because they use the processing power of a powerful server machine.

Reality Check This is not necessarily true. Today's desktop clients are rarely deficient in terms of memory and CPU power. Most of the bottlenecks on a two tiered client are due to database access and database transactions. When you build a middle tier, you are obviously putting another layer between the database and the client. How does that help the situation? To be honest, it does not. In most cases you will find that your distributed application performs slower than an equivalent 2-tiered application. However, you may see performance benefits in the following scenario -

1. When the middle tier caches data. Example - large and complex lookups, data for validation etc. This reduces database access which will be beneficial when there are a large number of users.
2. When the middle tier uses transaction pooling. Again, this is beneficial when there are a large number of users.
3. When your application uses super-thin clients like HTML browsers. In this  case, since most of the processing happens on the server, you can boost performance by adding more CPU power and memory on the server.
4. When the application contains a lot of transactional logic that requires fetching and processing huge result sets. For example interest calculations, batch processes, long reports etc.

Hype: Fat clients are bad as they hog desktop resources

Reality Check: Hey?!! Isn't that the whole point of Client/Server computing - all the clients take up some processing load so that we can have server machines that are less than mainframes? And as long as people use applications like Microsoft Office the desktops are sure to have plenty of processing power anyway. It would be foolish not to utilize this processing power when available and unnecessarily buy more expensive hardware on the server.

Hype: Distributed systems simplify development

Reality Check: Not true. If you consider the issues I highlighted earlier, you will realize that distributed systems actually add a lot of new complexity to application development. Sure, your system is going to be more cleanly designed cause you broke up everything into neat little pieces and spread them across multiple tiers. But it's no simple and easy task to make all these pieces work together.

Hype: Distributed systems are easier to maintain.

Reality Check: True. This is one of the most important reasons why I advocate n-tiered computing. If the system has been designed correctly, it becomes easier to adapt to changes in the business logic. The efforts that go into changing the code are still the same. The real benefit is that the client software does not have to be updated. However, the assumption here is that the change in business logic does not affect the presentation layer. This may not always be true.

So when and why should I go in for a n-tiered architecture?

I believe that you should consider distributed systems in the following scenarios-

1. Business logic is extremely 'volatile' and changes need to be propagated quickly.
2. When you have different types of clients accessing the same business logic.
3. When the application has to support a large number of users (typically the number of users exceeds about 100).
4. The users are geographically dispersed.
5. When you are building web-applications that use super-thin web browser clients.
6. For intensive server side processing like batch processes and reports servers.

Introduction

Strategy
Building the monolith
Building the PB Client
Building the DPB Server
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:

Plumbing - Steve Benefield's PBDJ editorial

Development trends: today and tomorrow