There seems to be a lot of "sound and fury" concerning the move from PowerBuilder to the Web. I'm convinced, however, that the majority of PowerBuilder developers don't know how to get there. Many of those who have taken that course have found it more difficult than they first anticipated. If you're in the latter boat, perhaps this article won't be of much interest to you - you've already earned your battle scars. For those of you who have yet to venture into the minefield, perhaps I can guide you along the way.

I believe one of the problems PowerBuilder developers face when trying to move to the Web is the variety of options on how to get there. There's the DataWindow plug-in, the window plug-in and ActiveX, and the PowerBuilder Web Deployment Kit. Other options include generating HTML pages from PowerBuilder using the SaveAs() and GenerateHTMLForm() methods, accessing the DataWindow.Data.HTML or DataWindow.Data.HTMLTable properties, or using the Web.PB libraries that came with PB 6.x. The middle-tier PowerBuilder objects could be written as Distributed PowerBuilder applications accessed through Web.PB; they could be deployed directly into EAServer as CORBA objects or compiled into COM objects and deployed into a number of application servers (most likely MTS, but EAServer could be used here as well). If you've deployed your PowerBuilder object into EAServer, either as a COM or CORBA object, there are a number of options on how the dynamic page server "client" can access it. EAServer allows the developer to generate an ActiveX proxy, or C++ or Java stubs that can be used to access either type of object. Finally, while Sybase might prefer that you use PowerDynamo (included in EAServer) as the dynamic page server, once the objects are in an application server there are a number of dynamic page servers that might be considered. This isn't a complete list of all the possible options, but trying to consider all of them can certainly be exhausting!

Narrowing the Choices
There are a number of those options that I'd like to discount at the start. The plug-ins, the ActiveX control, the SaveAs() and GenerateHTMLForm() methods, the DataWindow. Data.HTMLTable property, Web.PB and the Web.PB class library, and Distributed PowerBuilder all represent Sybase's earlier efforts in their movement toward adding Web capability to PowerBuilder. In some cases, the functionality provided is very specific (and limited). In particular, the plug-ins and the ActiveX control aren't good options if you're considering moving applications to the Web in general.

In other cases, Sybase's continued support for those options is in question. The PowerBuilder 7.0 release notes indicated that a number of companion products that had been shipped with prior versions of PowerBuilder were now obsolete and would no longer be shipped with the product, among them the Web.PB class library. In addition, the release notes also indicated that Distributed PowerBuilder and Web.PB wouldn't be supported beyond PowerBuilder 7.0.

While the SaveAs() method and the DataWindow.Data.HTMLTable property render fairly similar results, they're also comparable to what's returned from the DataWindow. Data.HTML property if the DataWindow's HTMLDW property is set to "No." As a result, these two options are pretty redundant and of the three, only the DataWindow.Data.HTML property should be considered further.

The GenerateHTMLForm( ) method generates something similar to what the DataWindow.Data.HTML property generates when the DataWindow's HTMLDW property is set to "Yes." The primary difference is that the GenerateHTMLForm( ) method returns an argument for every row/column combination in the form, whereas the form generated through the DataWindow.Data.HTML property returns only two arguments, context and action, regardless of how many row/column combinations are contained in the form.

• Context: Contains all of the data in the form
• Action: Tells the program which action the user requested to be performed on the data

The GenerateHTMLForm( ) method would be useful for generating forms used to submit data to an application through CGI (which does expect a separate argument for each parameter passed). That's precisely how Web.PB worked.

However, there are some distinct advantages to the two argument approach of the form generated with the DataWindow.Data.HTML property. The first is: there are native PowerBuilder functions added with PowerBuilder 7.0 that can take the context and action arguments and directly apply them back to a DataWindow. The second is more subtle and has to do with maintenance. Each time you add or remove a column with the GenerateHTMLForm( ) method, the function on the user object that received the data from the user has to be modified to add or remove an argument, and the code within the function has to be modified to add or remove references to that new data element. With the DataWindow.Data.HTML approach, the function method and in many cases the function itself can operate independently of the actual data context. As a result, much less work is required to accommodate changes in the data set being passed.

That leaves us with two main choices:

1. Using the PowerBuilder Web Deployment Kit
2. Using the DataWindow.Data.HTML property to generate HTML (also known as the HTMLDW or the WebDW), deploying the objects into an application server either as a COM or CORBA object, and subsequent decisions about which application server and which dynamic page server we want to use.

1. Which of these two approaches makes more sense?
2. How much of the application do we need to move?

Existing PowerBuilder Client/Server Applications
We'll look at existing PowerBuilder-based client/server applications first. One of the primary reasons for moving applications to the Web is to reduce the infrastructure costs, particularly with regard to deployment. In the case of existing client/server applications, a great deal of that cost may have already been expended. Such applications might also be "mature" enough so there's little need for deploying new versions of it and the user base isn't expanding greatly. In these situations there doesn't seem to be much of a case for moving such an application to the Web.

However, if the product is still relatively "immature" and is encountering frequent upgrades, or if the user base is expanding rapidly, which results in a continuing deployment cost, then moving the application to the Web makes more economic sense. In this case, the next thing we want to look at is how much of the application it makes sense to move to the Web. For example, at one of my client sites we looked at an application and determined that the majority of users required only read-only access to a number of reports. There were only a handful of users who actually needed access to the entire application. As a result, we moved the reports to the Web using the DataWindow.Data.HTML property to generate the reports as HTML. The native PB client portion of the application was modified so that it launched the browser to the Web page for those users who did require full access to the application.

In another scenario, one of my clients was undergoing a consolidation of what used to be several different offices into a single office. One of those offices, with about 3,000 users, had been doing client/server work for some time and had all the deployment issues pretty well in hand. The other sites, with an additional 6,000 users, weren't anywhere near as far along with client/server or with resolving large deployment issues. The applications developed by the first office now needed to be deployed to an additional 6,000 users; however, the infrastructure that would make it a simple operation was not in place. Here's a great business case for deploying the applications over the intranet: the cost of the additional deployment could be largely avoided. The problem is that we're talking about 100 or more PowerBuilder applications that would all need some degree of rewrite in order to be deployed as "true" Web applications, and the cost of that rewrite would equal or exceed the cost savings from Web deployment. What seems to make more business sense here is the PowerBuilder Web Deployment Kit.

PowerBuilder Web Deployment Kit
The PowerBuilder Web Deployment Kit (PBWDK) seemed to make a splash when announced at the 1998 Powersoft User Conference. However, interest seems to have waned, perhaps because of the time it took for the product to actually arrive. It's unfortunate, as the PBWDK does work well in the niche it's designed for. For those not familiar with the PBWDK, it operates by running an instance of the application on a middle-tier NT server. Native functions in the Windows NT API are then used to reroute the user interface portion of the application to a client workstation. The client portion is launched from a plug-in or ActiveX control in a browser, hence the Web deployment. (The application doesn't run within the browser; it appears to run on the client as if it was running there locally as a Windows application. The browser is simply the deployment method.) There's a small runtime that has to be installed on the client, but that same runtime is used for every application that's Web enabled with the WDK. That runtime can also be deployed on an as-needed basis through the browser, simplifying deployment greatly.

One obvious limitation of this approach is it requires NT servers to run the application on (and many of them to support a large number of concurrent users). There are competing products in this marketspace that suffer from the same limitation. In addition, the client runtime is a native Windows application, which means it (currently) works only for Windows clients. Competing products use a Java application on the client, making them applicable on a broader range of client-operating systems. However, my own experience shows that those Java-based runtimes run significantly slower than the native Windows runtime used by the PBWDK. Therefore, if you're supporting only Windows clients and client performance is an issue, the PBWDK approach offers a significant advantage over the competitors. An often overlooked feature is that the PBWDK comes out of the box with support for load balancing between servers in a cluster through "PBWDK server farms." Finally, although application-use problems are sent to the server NT log, they can also be routed to an e-mail address so the administrator can resolve them (as needed) with a more real-time response time.

New PowerBuilder Applications
Existing applications that are undergoing or are about to undergo significant modifications can be handled pretty much the same as new applications. If the cost of rewriting most of the existing code is already being considered, then rewriting that code so it can be called from a Web client shouldn't add significantly to that effort. For new applications and existing applications undergoing significant modifications, I once again prefer the DataWindow.Data.HTML property approach (the HTMLDW). While I've become a big fan of using the PBWDK for existing applications, I wouldn't write new applications in PB and use it for deployment.

The choice of how to deploy those newly written or rewritten components (COM or CORBA) will depend a great deal on whose component server you'll end up using (something that may not be under your control). If you have the option to use EAServer, then do so. You can deploy the objects as either COM or CORBA, but CORBA is the more native method and allows for remote debugging. If you've been told another component server is already the corporate standard (e.g., Microsoft's MTS) and it supports COM, then COM will be your only option. Currently PowerBuilder supports the deployment of CORBA components only in EAServer.

You may find yourself similarly constrained in the choice of a dynamic page server. For example, while you may be able to deploy your components into EAServer, and EAServer has PowerDynamo essentially "built in," you may find corporate standards dictate the use of a scripting language that requires a different server product (e.g., ASP or ColdFusion). In the case of one of my clients, ColdFusion is the de facto standard. The approach there is to code ColdFusion pages that call PowerBuilder components in EAServer. For a number of reasons I found we needed to use the ActiveX proxy that Sybase provides so ColdFusion could make COM object calls to the CORBA deployed PowerBuilder object. The reasons were twofold:

1. ColdFusion supports two methods to access the server hosting the object, IOR and NameService. PowerBuilder/EAServer currently supports neither.
2. There's an issue with each of the two ColdFusion methods used to call CORBA objects (CFOBJECT and CreateObject) that makes such use somewhat problematic.

Conclusion
Taking your PowerBuilder application to the Web can be an intimidating task because of the number of options available for making that migration. By looking at the various options and determining which are most appropriate for moving forward and using with the particular application you're moving, the task can become much more manageable.