(July 25, 2008) - Back in 2002, Sybase announced their four-phase approach toward adding .NET support to PowerBuilder. Phase 1 was the implementation of web services in PB9 and Phase 2 was the release of DataWindow.NET, which was packaged with PB 10. Phases 3 and 4 were the more significant phases. In Phase 3, Sybase added a number of .NET target types to PowerBuilder 11 and added support for calling non-visual .NET assemblies from PowerScript. The 4th phase will be completed in PowerBuilder 12 and involves “...support for Windows Presentation Foundation (WPF) ... as well as full support for visual controls and drag-and-drop programming with .NET within the IDE”.1 We’re at the mid-point between the release of PowerBuilder 11 (phase III) and the release of PowerBuilder 12 (phase IV, which should complete .NET support). I thought it might be beneficial to review the progress so far and reassess what the future looks like.

Web Services
While PB9 did provide some original support for web services, it wasn’t until the 10.5 release when the .NET engine was added that such support became highly useable. The previous engine, built on the EasySOAP open source library, became largely feature frozen in 2002 when the EasySOAP project essentially became abandonware (http://en.wikipedia.org/wiki/Abandonware). The .NET engine introduced with PB 10.5 did bring the client proxy creation capability to current standards, but there are still some problems with the implementation. For example, PowerScript functions can’t return arrays, and the proxy object is limited to what PowerScript can support. As a result, you currently can’t create a proxy for a web service method that returns an array and expect to be able to do anything with the result (it gets cast as an “any” data type). There is also currently no support for WS-Security (most likely because that’s an add-on feature for .NET 2.x, not part of the original SDK) and for protocols other than SOAP (e.g., REST, JAX-RPC). It’s possible that those latter two issues will be addressed as Sybase implements support for WCF (Windows Communications Foundation) in PowerBuilder 12.0.

DataWindow.NET
DataWindow.NET hasn’t stood still since it was first introduced and packaged with PowerBuilder 10 either. Version 1.5 introduced the WebDataWindowControl. Version 2.0 added support for ADO DataSets as a data source, the TreeView presentation style and autosize height for non-detail bands. Version 2.5 finally brought the DataWindow Designer into the VS IDE, added support for the TreeView presentation style to web DataWindows, and added web services as a data source.

There are still some impediments to acceptance of DataWindow.NET into traditional .NET shops though. The first is the requirement to keep the DataWindow source in a PBL. A PBL makes sense to PowerBuilder developers because the compiled version of objects is kept there. It makes absolutely no sense in a VS.NET environment, particularly because a DataWindow isn’t compiled. It makes it confusing for new developers to get started and hinders proper source code management. Perhaps a bigger issue is the amount of work it takes to deploy an application that uses DataWindow.NET. The developer has to remember to include the PBD that contains the DataWindow, four or more unmanaged code runtime files, and (if PDF is used) download and install GhostScript.

WinForm Targets
WinForm targets were introduced in PowerBuilder 11, which is pretty much just a .NET compile of the Win32 version of the application. Somewhat akin to the machine code compilation, the PB source code is converted to C# and then compiled. One difference though, introduced in PowerBuilder 11.1, is the ability to do an incremental compile (machine code compiles are always an all or nothing proposition).

In the future, this particular target may become more useful as Win32 is phased out in future versions of Windows. However, at the moment, the primary advantage of this particular target is that you can include conditional code blocks within PowerScript that reference non-visual .NET assemblies (either .NET system assemblies or third-party assemblies) and that code becomes active when compiled in a WinForm target.

Unfortunately, the syntax that you need to use within the conditional code block is neither C# or PowerScript, but a morph of the two that is poorly documented and does not yet provide full support for all .NET language features. That, and the limitation of such usage to non-visual assemblies, has restricted the traction this particular feature has obtained. Because there are some Win32 features that are not supported in a WinForm target, a lot of testing that has to be done to ensure that a WinForm target works the same as the Win32 version and it has limited advantages.

Perhaps a bigger question surrounds the future of WinForms, regardless of the tool used to create them. Microsoft added WPF (Windows Presentation Foundation) to .NET as of version 3.0. There is a great deal of emphasis on it as the future for doing graphical interfaces. This has resulted in a great deal of debate within the .NET community about whether WPF is currently robust enough to handle LOB (line of business) applications.2 Sybase has already demoed the WPF DataWindow, so they are working toward supporting WPF.

SmartClient Targets
SmartClients are actually a subcategory of the WinForm target, but I thought that they are worth a special mention. This is the other major advantage I see to a WinForm deploy, the ability to deploy a “rich client” application to a client without the impact on the client configuration that rich clients generally require. Usually this feature works well. There’s still some area for improvement though, mainly having to do with the ability to easily customize how the application is deployed (how the web page appears, etc.). ClickOnce technology, which the SmartClient is based on, is also supported as a deployment option for WPF-based applications, so we should continue to have that capability regardless of whether we use a WinForm or WPF approach in later versions of PowerBuilder.

WebForm Targets
WebForm targets provide a fairly representative rendering of the Win32 application running in the browser. A number of features, significantly more than WinForm targets, are not supported because an application running in the browser has limited access to local system resources (e.g., it can’t launch an application on the client such as Word or Outlook and manipulate it using OLE Automation). Nonetheless, it does offer a fairly reasonable way of moving PowerBuilder applications to the web.

One of the significant improvements Sybase added in PowerBuilder 11.2 was AJAX support for WebForms, so that only portions of a page are refreshed on a postback, rather than the entire page. A typical PowerBuilder application (e.g., one based on PFC) will still likely generate a lot of unnecessary postbacks because it was not originally designed to avoid them. This might mean that significant refactoring of the code is required in order to support both Win32 or WinForm deployment and WebForm deployment.

There are currently two major technical obstacles to widespread adoption of WebForm targets as a means of deploying PowerBuilder applications. The first is browser support. The current implementation is pretty much limited to Internet Explorer. In some companies where a particular browser is deemed a company standard and is the only one supported, this might not be such a barrier. In many cases, however, developers are not in a position to require end users to only use one particular browser. The other major issue is the unmanaged code that the current version of PowerBuilder still relies on, particularly for the DataWindow control. Many web server administrators will balk at the idea of deploying unmanaged code to a shared web server, because unmanaged code could cause errors that could take down all of the web sites running on the server. Even if they were comfortable with the use of unmanaged code, the current requirement to deploy it into a directory that is referenced in a system environmental variable is a bit much to ask. The typical deployment scenario should only involve copying the files into the root or bin directory for the application.

Another issue I have with WebForms is that they do look very similar to the Win32 application. Some folks might like this (saves retraining), but I *expect* a web application to look different from a Win32 application. What I would like to see (though I have no idea how they might implement it) would be something along the lines of PocketBuilder’s MOP view manager, except on steroids. For those of you not familiar with PockerBuilder, one issue with deploying to mobile devices is the wide variety of screen sizes available. To deal with this, the PocketBuilder folks added a Multiple Orientation Painter (MOP) view feature. You take the same window, indicate what particular screen size (and orientation) you are supporting, and then arrange the controls on the window to suit that particular size and orientation. Then you switch to a different size and/or orientation and adjust the layout for that new selection. The key is that PocketBuilder remembers the different settings for the different sizes and orientations and adjusts automatically at runtime based on the device. My “super MOP” approach would allow for the same adjustments between different target types (Win32, WinForm, WebForm and, down the road, various end targets for WPF). You indicate which particular target type you want to customize the window for, and then adjust it for that target type. The kind of control that you would need to have would be much more extensive than what the PocketBuilder MOP view handles though. For example, it’s fine in a Win32 application to have an MDI frame and sheets, but in a WinForm (and down the road WebForm) I might want that rendered as tabbed MDI instead, and in WebForm I might want the “sheets” to result in movement between entirely separate web pages (which modern browsers would end up rendering as tabs within the browser).

ASP.NET Web Services
The ASP.NET Web Service target allows the developer to deploy PB non-visual objects as ASP.NET web services, similar to what they have been able to do in the past through EAServer. While it is very simple to use and works well, it does have some of the limitations mentioned earlier. Like the web service client, the ASP.NET web service is hindered by the PowerScript limitation on returning arrays from functions. Therefore it’s not possible to return an array from a PB-based ASP.NET web service. Instead, a reference argument has to be added to the method to return data that is returned in an array. Also, like the WebForm target, ASP.NET Web Service targets face a deployment challenge because they currently rely on unmanaged code that has to be deployed to a directory in the system path. Finally, like web service clients, PB-based ASP.NET web services are not currently capable of supporting WS-Security. Hopefully, the support for WCF in PowerBuilder 12 will enable such support as well as support for protocols other than SOAP.

.NET Assemblies
The .NET assembly allows PB developers to compile non-visual custom classes as .NET assemblies. I’m not sure if Sybase plans to support compiling visual custom classes as well at some point. I haven’t found a whole lot of use for this particular target yet, but the unmanaged code that you might need to drag around with the resulting assembly could be a potential issue.

What the Future Holds
PowerBuilder 12.0 isn’t actually the next major release in the works; 11.5 is just around the corner. Although it is a major release, Sybase has indicated that they will not be charging an upgrade fee for existing 11.x customers. Most of the enhancements are related to GUI features rather than additional .NET support (see http://powerbuilderevangelist.blogspot.com/ for a preview of coming attractions). According to the current plan, it won’t be until 12.0 that we see the next major .NET enhancements.

However, I’m left wondering if we don’t need yet another incremental release (11 3⁄4?) between 11.5 and the final .NET release. I could use the web services enhancements that would come with WCF support (WS-Security and non-SOAP protocols) today. I’d also be interested in being able to deploy the existing target types in such a way that didn’t require unmanaged code, perhaps through embedding the WPF DataWindow rather than the standard DataWindow (assuming that buys me completely managed code). On the other hand, while I’d like to be able to generate full WPF targets and gain more .NET functionality (e.g., visual controls), I can live without those for a while longer.

References

• Waters, John K. "Sybase Releases PowerBuilder 11 for .NET." Redmond Developer News.
• Arguments for WPF
• Arguments for WinForm