Last month I started a series in which I'll be looking at some of the important new technology offerings Sybase showed at TechWave and share with you my comments (good or bad) about those technologies.

Last month's topic was the PowerBuilder Application Server Plugin (PASP). This month I want to discuss the ASP.NET Application Deployment feature slated for PowerBuilder 11.

ASP.NET Application Deployment in PB11
This particular feature has been in the works for a while, but it wasn't until I saw John Strano's demo during the tools keynote that I started developing an interest in it. Everything I had seen or heard of so far was, like Appeon, a literal translation of an existing client/server application onto the Web. What you end up with isn't so much a true Web application, but a simulation of a client/server application within the browser. Dave Fish also presented a similar demonstration during a later Webcast, a recording of which is still available at www.placeware.com/cc/sybase/view?id=PowerBuilder+10.5+Preview&pw=PB+10.5. The key thing to note during that Webcast is that the application was created with a Web application look-and-feel in the painter.

Last month I noted that the removal of Distributed PowerBuilder left the only "significant" method of creating distributed applications with PowerBuilder dependant on EAServer. There was another method. You could create COM components, deploy them to MTS, and then write a Web application that interacted with them. The problem was that it wasn't entirely straightforward.

Where I see ASP.NET application deployment really addressing a need is for those people who are interested in doing distributed application development with PowerBuilder but don't want to use any EJB server to get there. Previously they might have used the COM component approach, but the ASP.NET application deployment provides the simplicity of implementation that the COM component approach certainly lacked.

The issue with the whole ASP.NET application deployment approach is that it (like Appeon) is based on a false premise - that thin-client (Web) applications and rich-client (client/server) applications are similar enough that I can either convert a rich client to a thin client with no GUI changes, or I can maintain a single GUI code base to support both. I think that's nonsense. If I want to have both a thin- and rich-client version of the same application, what I will want to do is maintain a GUI-neutral business logic layer, which both clients talk to. I would then develop independent GUIs, one for the thin client and one for the rich client. The main advantage ASP.NET application deployment could provide is a common scripting language used in both the thin and rich client.

Of course, if smart clients do take off, they could render the whole argument moot, so Sybase needs to stay on top of that ball as well. But until then, I think that ASP.NET application deployment needs a bit more refinement, in particular, an all-or-nothing compile won't do. You have to be able to develop and deploy some components as independent assemblies so they can then be called by more than one client.

My other concern here is the delay between the release of ASP 2.0 and the release of PowerBuilder 11. I know that the PowerBuilder development team has been burned in the past by Microsoft's post-beta/pre-GA changes to technologies that the PowerBuilder team was coding to. However, I'm not convinced that the length of the delay can be solely attributed to the resulting caution about being burned again. I'm also concerned about how much later important core functionality (such as something other than an all-or-nothing compile) would be made available if it's not part of the original release.