Welcome!

PowerBuilder Authors: Chris Pollach, Yeshim Deniz, Jayaram Krishnaswamy, Kevin Benedict, Avi Rosenthal

Related Topics: PowerBuilder

PowerBuilder: Article

Building .NET Web Applications the Easy Way

How to modernize PowerBuilder apps

In the last few years many customers I consult for have asked how to modernize their PowerBuilder applications and their development skill set. They want to go to the Web, they want to embrace .NET, and, in general, they don't want to fall behind. I can sense their anxiety, but there are some good approaches that make this transition relatively quick and easy. This article is intended to help all those in this predicament.

Most customers I speak to basically tell me the same thing, "We have client/server applications that work well, we've invested a lot of resources to develop them, and PowerBuilder is a very fast and easy tool. But we need to keep up with the times and, going forward, our projects need to be Web-based." As they tell me this, I can hear the voice inside their head that is really asking, "What are we to do? Do we really need to junk our existing client/server applications? Do we have to retrain our development team? Do we have to hire new .NET developers who know nothing about our business?"

The answer is no. Wipe the sweat away and keep reading...

Dominant Approaches
There are two fast and easy ways to transition from PowerBuilder client/server development to .NET Web development. This article evaluates them. The first is to utilize a PowerBuilder add-on that has been around since 2001: Appeon 6.0 for PowerBuilder. Appeon can be purchased through Sybase, separately from PowerBuilder. The second approach is to take advantage of the new .NET WebForm deployment capability, introduced by Sybase in 2007 as an integral part of PowerBuilder 11. This won't cost you a dime if you are current with your license renewals.

Both approaches can get PowerBuilder developers to the Web and .NET faster than anything else out there, but there are notable differences to understand. To get to grips with this, I took an actual client/server application and transitioned it to the Web and .NET using each of these approaches. Then I evaluated them based on several key criteria. After you have read this article and the comparison, you should have a good feel for the differences between the two transition approaches. And, hopefully, you will be able to judge better if they are appropriate for your projects and technical requirements.

Under the Covers
PowerBuilder's WebForms ("PBWF") and Appeon for PowerBuilder ("APB") are conceptually the same. With both, you work in the PowerBuilder IDE leveraging DataWindows, visual objects and controls, system functions, and PowerScript (including PFC). Both deploy your PowerBuilder project to the Web and .NET Framework. Both officially support just the Internet Explorer Web browser. Both render a Web application with a PowerBuilder-like user interface.

What about internals? Well, I've not been lucky enough to examine the source code of either PBWF or APB, but I do know for certain that both have developed essentially a PB-style framework on top of the existing .NET Framework (somewhat analogous to the extension layer in relation to PFC). The only notable difference at a glance between the two approaches is the architecture. Most processing with PBWF happens on the server. It utilizes ASP.NET and AJAX for the presentation layer. APB does significantly more processing at the Web browser. It utilizes HTML, JavaScript, AJAX, and a generic ActiveX plug-in.

The Evaluation
As mentioned, I evaluated both approaches using an actual client/server application. I essentially had two objectives. First, I wanted the evaluation to be as realistic as possible and applicable to most people. Second, I wanted it to measure various criteria that I have found to be key to any successful transition project.

I chose to challenge PBWF and APB with a client/server application developed several years ago. This is not as massive or as complex as other client/server applications I have seen but, nonetheless, it is more demanding than just a few vanilla Web pages, such as a shopping cart or a directory listing. Furthermore, for the sake of realism, I wanted to use an application that was not specifically developed for this evaluation.

I deployed the same client/server application to the same client PC and server, using PBWF first and then APB. I evaluated both approaches against the following five criteria:

  1. Deployment process: Overall Web deployment experience
  2. Deployment tools: Tools available to aid developers through the deployment process
  3. Unsupported features: PowerBuilder features that do not convert over to the Web
  4. User interface: The resulting Web application's look-and-feel
  5. Performance: Responsiveness of the Web application and actual hardware resource consumption

The Client/Server Application
I selected our Enable sample application, used by us to demonstrate our multilingual capabilities for projects to internationalize PowerBuilder applications. It's a basic MDI application with various windows, controls, DataWindow presentation styles, and other PowerBuilder features. It uses the Enable multilingual PowerBuilder framework, so it can dynamically switch between various languages. Most importantly, in a search for some degree of realism, we designed the application to represent a typical subset of a data-centric application, as encountered at customer sites.

Take a look at the original client/server application (running in Italian here): the "Controls" window (see Figure 1) uses many PowerBuilder controls; the "Shared DataWindows" window (see Figure 2) contains a computed field and a DataWindow button; the "Presentation styles" window contains various DataWindow styles, including a group DataWindow (see Figure 3) and a Crosstab (see Figure 4).

The Enable multilingual framework is typically distributed as PBDs. However, both PBWF and APB require the libraries' source code (i.e., PBLs) to convert to the Web. So, for purposes of this evaluation, I used a PBL version (generated with our Powerscript Obfuscator technology) instead of the PBD version.

The following paragraphs discuss the results of the exercise described above, with reference to the five key criteria.

Deployment Process
This involves configuring the Web project and then deploying it to IIS with the .NET Framework. The actual IIS setup is excluded, since this and the .NET Framework were already installed.

PowerBuilder WebForms
Define a new WebForms target based on an existing standard (client/server) target. Specify simple things, like application name and additional files. The initial Web deployment felt a little sluggish, but subsequent Web deployments are done incrementally, so they'll be much faster and manageable. To make the Web application work correctly, you need to set up AJAX, user rights, etc. but this is all documented and fairly straightforward, if you read the product manuals before getting started.

Appeon for PowerBuilder
Press the "Config Wizard" icon and answer a series of straightforward questions: application name, workspace/target, define your database connection, map the connection to your transaction objects, attach any INI files used, attach any DLLs or OCXs you want to embed in the application (APB supports OCX and other external objects running in the Web browser). Deployment seemed somewhat faster than PBWF deployment, but I didn't time it as both were within acceptable limits. APB also supports incremental deployment.

Available Tools for Deployment
This looks at the various tools available to assist with the Web deployment process and their usefulness. Compared to client/server, the Web architecture is daunting and anything that helps make sense of the process is welcome.

PowerBuilder WebForms
PBWF provides all the essential tools needed to deploy the client/server application to the Web: a report listing all the unsupported features included in my application and a Web debugger.

Specifically, PBWF produces a simple report listing all the unsupported features in the output windows. The format is not very user-friendly, but there is a nice tool available on CodeXchange (with source code) that can enhance the usability of this report.

The source code debugger for WebForms is useful: it's the same as the native PB Debugger (i.e., it runs inside the PB IDE), but gives developers the ability to debug the Web application to understand why something isn't working as expected.

Appeon for PowerBuilder
APB offers all the same tools as PBWF, plus Code Insight. Code Insight is essentially the same thing as VisualStudio's IntelliSense, with one important difference: it lists only the PowerBuilder client/server features that are supported on the Web. As such, you don't have to worry about introducing any new unsupported features while writing new code. As a side note, although the Appeon Web debugger looks like the PowerBuilder debugger, the underlying engine is in fact the Microsoft Script Debugger.

Unsupported Features
This considers how many unsupported features were identified using the two approaches. More unsupported features mean more development work to deploy applications to the Web. For new Web projects, more unsupported features mean fewer features in the Web application with respect to those frequently found in client/server applications.

PowerBuilder WebForms
PBWF flagged 486 unsupported features. Many of them were properties or, in general, not too critical; I decided not to work around these unsupported features, since they had no significant impact on the Web application. Some things did need to be rearranged, like the GetFocus event and the Title property for DataWindow controls. As a side note, a few unsupported features were actually marked as errors (e.g., the Window.Transparency property); all errors must be removed before continuing.

Overall, I made a few minor changes without rewriting any of the unsupported features, and then I was able to deploy the client/server application to the Web.

Appeon for PowerBuilder
APB flagged 57 unsupported features. None of the unsupported features caused the Web deployment to fail or produce error messages. Nothing had to be rearranged. I didn't make any changes to the code or rewrite any of the unsupported features.

User Interface
This involves evaluating the user interface of the Web application, focusing on the overall look-and-feel, usability, and aesthetics. A good user interface is important, since it can boost the end users' productivity and, most importantly, gain their praise, as always, paraphrasing, the "end user is king" when it come to technology.

PowerBuilder WebForms
The user interface is good and looks better than typical ASP.NET Web pages. It's actually quite similar to PowerBuilder, but with a Web flavor. For example, the MDI windows are replaced by tab pages similar to the tabbed Web browsing of Internet Explorer (see Figure 5 and Figure 6). The Web application is multilingual, with the ability to change language dynamically.

Overall, although the MDI was lost, it essentially resembled the original client/server application. This is a plus, given that the development community is shifting to Rich Internet Applications (RIA) that essentially merge the user interface of client/server applications with the accessibility of the Web.

Appeon for PowerBuilder
The first time I ran the Web application it automatically downloaded and installed a ~2MB ActiveX control. There was an initial start-up screen that clearly shows the progress of the download. Once the ActiveX had been downloaded and installed, the Web application started automatically.

The Web application looks identical to the original client/server application. In every aspect, look, feel, behavior, I felt no difference except, obviously, it was running in the Web browser. The MDI and all other user interface constructs were faithfully preserved. But rather than try to explain in more detail, as the saying goes, a picture is worth a thousand words (Figure 7, Figure 8).

As expected, the Web application was also multilingual, with the ability to change languages dynamically.

Performance
This looks at the performance and efficiency of the Web application. I looked at both the largest and the simplest windows in the .NET Web application and measured the responsiveness in seconds as well as the related hardware resource consumption.

PowerBuilder WebForms
I opened the main window in the Enable sample Web application and retrieved data in the various DataWindows. It took 12.3 seconds to display that page and its corresponding DataWindows. That's 11.8 seconds slower than PowerBuilder client/server. The test was repeated three times to confirm the result. Keep in mind that this window, like most client/server applications, is much more complex than a standard ASP.NET Web page. By contrast, the simplest window opened in just 1.4 seconds, but wasn't as responsive as client/server when used.

In terms of hardware resources, Internet Explorer was consuming 50MB of RAM and IIS was consuming 75MB of RAM. I opened up three additional browser windows to simulate four concurrent users on IIS, just to see if IIS resource consumption changed with a few additional users. Each additional user seemed to deplete approximately 7MB of additional RAM. With four online users, IIS was consuming 94MB RAM. CPU usage was moderately intense during AJAX communication with the server, averaging 20% server CPU utilization. Of course this wasn't a true scalability test, simulating hundreds of users or more, but nonetheless did provide some indication.

Appeon for PowerBuilder
I opened the same main window in the Enable sample Web application and retrieved data in the various DataWindows. I did this three times to make sure that the results were consistent. I used the same machine as in the PBWF test, so the hardware, software, and all settings were identical. It only took 0.8 seconds to fully display the same Window and its corresponding DataWindows, which was 0.3 seconds slower than the client/server application and 11.5 seconds faster than PBWF. The simplest window also took 0.8 seconds to open and its responsiveness was similar to the client/server version.

In terms of hardware resources, Internet Explorer consumed 40MB of RAM and IIS consumed 23MB of RAM. I opened up three more browser windows to simulate four concurrent users on IIS just to see how things changed. The IIS memory consumption remained constant at 23MB. In other words, even with four online users IIS still consumed the same amount of RAM as a single user. The CPU usage on the server remained constant between 0% and 2%, with no spike in CPU usage during AJAX communication with the server at this user level.

Evaluation Summary
PowerBuilder WebForms
WebForms is a standard feature of PowerBuilder 11. It's particularly useful for deploying specific DataWindows and business logic to the Web, such as forms for completion by general users or reports to be viewed by management. The new AJAX support in version PB11.2 definitely boosts performance compared to version 11.0, but do not expect complex screens to run lightening fast.

Pros

  • Free of charge, included in the PowerBuilder Enterprise license
  • Excellent IDE integration and good overall development experience

Con

  • Limited performance (under certain circumstances consider reworking the code)

Appeon for PowerBuilder
This is a mature transition solution that has been enhanced and refined for many years. It's possible to build new .NET Web applications with robust functionality or migrate very complex existing client/server applications. Use of the ActiveX control allows for rich client-side integration, as well as drag-and-drop, hot keys, file functions, registry functions, etc. that typically you wouldn't expect on the Web.

Pros

  • Strong Web support for client/server PowerBuilder features
  • Impressive performance for complex and demanding screens

Cons

  • Not free (as always, consider the cost/benefit tradeoff)
  • Potentially not suitable for all users since an ActiveX is required

Final Words
PBWF or APB or something else? It really depends on the objectives and project requirements. Hopefully this article has provided a basic understanding of the two dominant approaches when transitioning to the Web and .NET. Although they are conceptually the same, architecturally there are obvious differences and, as such, it can be expected that the results will be different.

Finally, although this article focused on the Web capabilities of PowerBuilder 11, PowerBuilder 11 has an expansive feature set for transitioning to .NET, including WinForms, smart client, DW.NET, Web Services, and .NET assemblies, as well as the WebForms discussed here. So if you need to deploy to .NET but don't require Web access then you may want to evaluate the other .NET features of PowerBuilder 11.

More Stories By Gian Luca De Bonis

Gian Luca De Bonis is CEO/CTO of Enable Development, a London-based software house. He has considerable international consultancy experience, primarily focused on PowerBuilder, database technologies and software engineering.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.