White Paper

PowerBuilder Architecture - Strategies for a

3-Tier Environment

Overview

PowerBuilder has been a pre-eminent client server RAD environment and has
proved itself time-and-again to be a capable platform for swift delivery of data
dependant functionality. In recent years the industry has undergone a paradigm
shift away from client-server and to the more object oriented and business centric
3-tier model. Under the 3-tier model applications are broken down into different
layers: presentation layer, business logic and persistence. This partitioning allows
changes in one layer to be made without having an impact on the others, by
using clearly defined interfaces between the layers. The business layer allows
business logic to be defined and accessible in a unified way. Having this logic in a
single place, means that, in theory, multiple applications will be able to use the
logic and therefore development time can be reduced and complexity and risk of
system entropy mitigated. The partitioning of the user-interface allows changes
to be made to the user interface without having to rewrite the business logic.

Objective
The objective of this white paper is to give some guidelines on how best to
architect a 3-tier PowerBuilder application. It is generally acknowledged that
there has been a drift towards Java and specifically Java 2 Enterprise Edition
(J2EE) over previous years and that J2EE fits a 3-tier architecture very well.
However, people have begun to realise that J2EE development is costly and
requires some hard-core and expensive skills to make the most of it.

This white paper is assuming that the middle tier will be deployed to EAServer
and therefore that you are capable of deploying PowerBuilder objects as
components to the application server. We are also assuming that the
development is using PowerBuilder 9 and that the front end is capable of running
as a PowerBuilder application, a PowerDynamo web front-end or a Java Server
Pages (JSP) front end (amongst others). Anybody familiar with a Java
environment will recognise the concepts present within this paper, but the priority
for this paper is to illustrate some of the options available to architects when
working within PowerBuilder and also some of the pro’s and con’s of each
approach.

The 3-Tier Partition Layers

Data Layer
The area of three tier architecture that is likely to have least extra effort spent on
it when considering the move from 2-tier to 3-tier environment is the Data Layer.
Traditional relational databases do not match up exactly to an object based
approach but have a tendency to have some semantic relationship. For example a

Proprietary http://www.noblestar.com
© 2004 Noblestar Systems Corporation. All rights reserved.
row within a user table will have a very strong relationship to the object
representing the particular user. In a strong Object Oriented environment a single
instance of a class will represent the persistent attributes required. For a
relational database it is the difficult exceptions to the rule, which will cause the
most problems.

Business Layer
Within PowerBuilder the business layer is represented by non-visual objects,
which are deployed as components to EAServer. These components define the
classes, which your system will implement. As part of this deployment the
interface is exposed as Interface Definition Language (IDL).

Presentation Layer
The presentation layer speaks for itself as being the interface presented to the
user. Utilising a 3-tier architecture enables changes to business logic to not affect
the presentation. It also means that different front ends can be developed which
will use the same business logic.

The MVC architecture is not exclusive to a 3-tier implementation. If you already

have the MVC pattern implemented in a 2-tier application, then migration to three
tiers may well prove easier.

PowerBuilder
PowerBuilder has always been a tool, which allows for rapid development and
prototyping, attempting to give the highest returns to the investment in
development. As such the move to 3-tier has enabled some of the capabilities,
which make PowerBuilder such a productive tool to also be applied.

Prime amongst these tools is the datawindow. In a web environment the web-
datawindow provides a simple way to create or reuse data driven functional
areas. The interesting thing about the datawindow within a 3-tier environment is
that it completely contradicts the separation of presentation, business logic and
data. The datawindow embodies a presentation directly linked to the datasource
and as such is a difficult concept within our newfound 3-tier architecture.
However I have to stress that we must be pragmatic about our shiny new

Proprietary http://www.noblestar.com
© 2004 Noblestar Systems Corporation. All rights reserved.
architecture and not become dogmatic. If using the datawindow is going to offer
us many performance advantages in terms of development effort then we have to
weigh this against the hard labour of hand crafting presentation and then tying it
to business logic and data.

The circumstances in which the web-datawindow can prove to be most useful is in

the situation where a number of rows are being returned from the database and
are represented in a single datawindow. In this situation the web-datawindow is
both quick to develop and also easy to manipulate (in comparison with hand
crafted HTML generators). It will handle the update of multiple rows without
requiring logic for row iteration and update or modify calls.

Web-Datawindow Implementation
So what kind of alchemy and black-magic enables the web-datawindow? Do not
be fooled into thinking this is a complicated technology that you will have to
learn. And do not be fooled into ignoring the generated code from the 4GL web
page. Looking at the source can be most enlightening.

You will see that the web datawindow is nothing more than a specialised
component deployed on EAServer. The component has access to the given
datawindow objects and at run time will access these objects as datastores within
the component. The transaction object is set and the call to retrieve is issued.
The final part of the jigsaw is when the Generate() method is called. This method
is simply calling the datastore.describe(“datawindow.Data.HTML”) method. The
call to this method returns the results of the datawindow in the form of HTML .
This generated HTML is then returned to the dynamic page server (EAServer
JSP/Dynamo) in the form of a String. The page server then inserts the value of
this string into the page and returns it to the browser.

An interesting side note to the String that is produced is the amount of JavaScript
that is included. With no modifications the datawindow will return an amount of
script that may not be needed and can grossly inflate the payload to be delivered
to the browser. However, all is not lost. There are two approaches to this.

Proprietary http://www.noblestar.com
© 2004 Noblestar Systems Corporation. All rights reserved.
The first is to limit the amount of script being returned by using the SetWeight()
function. This function sets the amount of script to be returned by setting
indicators. The parameters are as follows:

• boolean allowupdate,
• boolean validation,
• boolean events,
• boolean clientscriptable,
• boolean clientformatting

If one of these is not needed in your particular datawindow then ensure that the
value is set to false.

The second way of reducing the amount of script served to the browser is by
caching the script within the browser. This way the browser will check whether it
has an up to date version of the script stored in its cache. If the version is up to
date then the browser will get it from the cache otherwise it will request the new
version from the server.

To fit in with our partitioned approach would require the datawindow to handle
data and presentation separately. This is a planned feature for future versions of
PowerBuilder and hand coding, while it could work, would take time.

Entity Model
In the J2EE world a number of different types of beans exist. We have entity
beans, session beans and message driven beans. For our purposes right now we
are interested in entity beans. These are beans or objects that represent
something persistent. The method of this persistence is not specific and could be
to memory, file or database. From our PowerBuilder point of view, the interesting
point is that a single instance of a class will encapsulate the logic for the
persistence of that data. So a class representing a bank account will be able to
create, update or delete that account. All that will happen on the class will be that
attributes are set, and then the business process decides what type of persistence
action needs to be applied.

In PowerBuilder this type of functionality can be implemented using server side

NVOs. Accessors and mutators (or getters and setters) will be created for every
pertinent attribute of the class. The will simply be functions with the standard get
and set methods i.e. String getName(), void setName(String name).

The client side component for retrieval will create an instance of the class and
pass it the database key to enable the lookup of the data. In order for the client
to receive the data it will have to call all of the get… methods for the appropriate
attributes.

The user will make changes to the data on the client side, whether it is browser
based or fat client based. Upon the user wanting to persist the changes the
system will call the set… methods for all of changed values. The system will then
call a method to persist that data e.g. save().

The advantages of this method are the decoupling of the user interface from the
business logic and the final persistence. It will allow multiple different clients to
use the logic without requiring amendments and will also allow the way the data
is persisted to change, again without affecting the client or presentation logic.

Proprietary http://www.noblestar.com
© 2004 Noblestar Systems Corporation. All rights reserved.
The disadvantage of this in a PowerBuilder world is that it takes time to develop
the logic and can be costly in terms of network calls.

Conclusion
Be pragmatic in choosing implementation strategy. The web datawindow offers
many advantages in terms of development speed and easily accessible
functionality. It is most suited to displaying and updating groups of rows in a
single transaction. In order to add flexibility and a more pure object oriented
development model data updates can be handled by using instances of server
side objects, similar to Bean Managed Persistence (BMP) in the J2EE model, but
the overhead from this methodology is in the development time and complexity
of implementation.

Derren Bibby
Chief Technologist
Noblestar Systems Limited
Liberty House
222 Regent Street
London
W1B 5TR
Office: +44 (0) 20 7297 2038
Mobile: +44 (0) 794 635 5238
Fax: +44 (0) 20 7297 2142
Email: mailto:[email protected]
Web: http://www.noblestar.com

Proprietary http://www.noblestar.com
© 2004 Noblestar Systems Corporation. All rights reserved.