 |
PUBLICATION Using
Distributed Objects in PowerBuilder for
Developing Internet & Intranet Applications
|
A 3-tier distributed architecture includes the following three components. Refer Figure 1.
Figure 1: Distributed Application Architecture
1. Database Server
It processes the SQL requests and returns results to its
client. In a 2-tier architecture its client is the GUI
front-end. In a 3-tier architecture its client is the
application server.
2. PowerBuilder
Application Server
You encapsulate the business logic of your application in
non-visual user objects. These objects, commonly known as
distributed objects, reside on the PowerBuilder
application server. All SQL requests are sent to the
database server by this server.
3. GUI Front End
This is the third component. It can be written using any
tool such as PowerBuilder, Visual Basic or Delphi. In a
three tier architecture, the front end development is
concerned with display and presentation of data rather
than processing of data which is handled by the
Application Server.
This article discusses the role of application server and non-visual user objects in the development of Internet and Intranet applications using PowerBuilder 5.0. It discusses the pros and cons of two different approaches for developing such applications.
Application
Server
The business logic for a 3-tier application resides
on the application server. This server also handles all
communications with the database. The client
communicating with this server can be any application -
it can be a PowerBuilder application running on an Intel
PC or Mac, or it can be a request from an Internet or
Intranet user. Using non-visual user objects, the
application server communicates with the database,
performs validations and returns information to the
client, if applicable.
Intranet
and Internet Development
PoweerBuilder 5.0 supports two approaches for development
of Internet and Intranet applications.
Approach
1 : Executable Content
This approach uses PowerBuilder window plug-in. It is
most suited for Intranet development. PowerBuilder
windows run as part of the browser window thus providing
sophisticated user interface to your Web applications.
The plug-in can also use PowerBuilder datawindows for
data presentation and update. With this approach, you
will need the following :
1. A plug-in enabled browser such as Netscape Navigator, Internet Explorer, etc.
2. A run time PowerBuilder window plug-in. This plug-in enables you to open a PowerBuilder window that can contain all of the standard PowerBuilder graphical controls such as tab controls, tree and list views, graphs and OLE objects. The plug-in can also make use of datawindows.
In this approach, all you need to create are the .pbd files. A .pbd file can be downloaded on the browser (client machine) and you see the PowerBuilder application windows on the browser screen. Refer Figure 2.
There are certain precautions you must take when programming such a system. For example - all PowerBuilder windows must be child windows, the code that links to the database must be placed either in the datawindow itself or be referred through a distributed object on the application server. Any validations in window scripts must be strictly avoided. Ideally, the .pbd files should be as small as possible. This enable easy download over the Net.
Figure 2: Executable Approach
Advantages
- PowerBuilder windows can run inside a browser. This eliminates the need to write extensive, customized HTML and CGI programs.
- Utilize a more sophisticated PowerBuilder user interface capable of supporting standard window controls
- Gain complete read/write/update and delete functionality using PowerBuilder datawindows
- Port existing PowerBuilder applications to the Web easily with few changes
Disadvantages
- If your browser is not plug-in enabled, you cannot take advantage of this approach
- All the PowerBuilder runtime DLLs must be present on the client machine. This consumes valuable hard disk space - approximately 8 to 10 MB.
- Large .pbd files may not be easy to download over the Net
Example
Figure 3 shows an example of a PowerBuilder child window displayed as part of the Netscape Navigator window. This window functions just like any normal PowerBuilder window except that it is displayed as part of the browser window. Such a window is part of the PowerBuilder library - a .pbd. The .pbd resides on the server. The browser loads the window when it encounters the following tag:
<embed src=windows_plugin.pbd width=370 height=320 window=w_product>
The windows_plugin.pbd is the PowerBuilder library. The w_product is the child window displayed in the browser window. The width and height parameters indicate size of the child window.
Figure 3: PowerBuilder child
windows within Netscape Navigator
Approach
2 : Dynamic Content
The dynamic content approach is essentially server
based development. With this approach, all you need is a
browser. No run-time DLLs are required on the client
machine. This approach is well suited for a wide range of
Internet users where you do not have knowledge of the
person who hits your site. It mixes Common Gateway
Interface (CGI) programming with HTML. Many new products
such as Cold Fusion use such technique.
You prepare a HTML page with forms and submit it to the pbcgi050.exe. This file - pbcgi050.exe - must reside in your Web server’s cgi-shl directory. It interacts with your PowerBuilder Application Server. The server in turn communicates with the database and the result set is dynamically shown on the client browser. For example, if you inquire for a specific product range, the inquiry goes to the Web server. The file pbcgi050.exe talks to the application server which in turn communicates with the database server and gets the product range in a datawindow. The datawindow is converted into HTML table and forwarded to the client browser. All this is done automatically. The only thing you need to code is the HTML form that sends the product inquiry to the Web server. Refer Figure 4.
Figure 4: Dynamic Content Approach
Advantages
- WWW users can experience dynamic, data-driven web sites
- Add database connectivity to your WWW site to deploy simple to complex server-based, transaction applications
- Simplified application maintenance and support. You make changes at one central location- the server
- Server based programming can be written using PowerScript instead of complex CGI programming such as PERL, C++, etc.
- No runtime DLLs are required on the client machine
Disadvantages
- Good working knowledge of HTML is required to design the client-side inquiry forms.
- It may lead to duplicate front end development. The developer may need to develop PowerBuilder Windows for the traditional PowerBuilder client/server applications as well as HTML Pages for Internet enabled applications.
Example
Let’s consider the example of making product inquiries using Web front end against your product database. A user object function of_get_data is defined that searches for the product description given the product name. The HTML code that calls the of_get_data function is as follows:
<FORM
METHOD="GET"
ACTION="/cgi-shl/pbcgi050.exe/of_get_data">
Enter product name to search on: <INPUT
NAME="product_name">
<INPUT TYPE="SUBMIT" VALUE="search
">
</FORM>
The PowerScript function of_get_data accepts one argument - the name of the product- and returns the complete description of the product.
Conclusion
This article identified the pros and cons of using
the executable content approach versus the dynamic
content approach for deploying Internet and Intranet
applications using PowerBuilder 5.0. What approach is
suited for your application depends on the specific
requirements and goals of your application.
A 3-tier architecture uses an application server as the middle tier that hosts the non-visual user objects. The business logic of your application is encapsulated in the non-visual user objects. PowerBuilder has introduced web.pb and Internet Development Kit that enable development using the techniques discussed in the article thus providing a complete Internet enabled application development environment.
