Back in late 2002 I wrote an article on creating Web Services using PowerBuilder ("Implementing PowerBuilder-Based Web Services from PowerDynamo" http://pbdj.sys-con.com/read/42210.htm). It was based on a PowerBuilder 8.0 component deployed to EAServer called from Web pages based on PowerDynamo that used DOM to generate HTML from the XML from the Web Service. Because PowerBuilder 8.0 didn't support the native generation of XML, PowerScript was used to generate it manually.

When PowerBuilder 9.0 came out, native XML was introduced. So were JSP targets. So I took that opportunity to rewrite the EAServer component with PowerBuilder 9.0 and rewrote the Web pages that accessed it using JSP. I wrote an article on how that was implemented in late 2003 ("Creating a Web Service with PowerBuilder" http://pbdj.sys-con.com/read/42590.htm). I was just updating the original component to take advantage of native XML support and using the Jakarta Xtags taglib library to do the XSLT Transform in the Web pages rather than PowerDynamo's DOM processor.

While PowerBuilder 10.0 did offer some Web Services improvements (automatic deployment of components as Web Services, UDDI support) it wasn't anything that really impacted my Web Service. Same for PowerBuilder 10.5 whose primary Web Service improvement (the new .NET engine) was entirely related to PowerBuilder clients consuming Web Services, not with Web Service creation.

That all changed with PowerBuilder 11.0.

PowerBuilder introduces several new .NET target types; of particular interest here is ASP.NET Web Services. So once again I'm re-implementing the Web Service to take advantage of features added with a new version of PowerBuilder (the third implementation of that service, hence the title of this article).

Creating the Web Service
The conversion of the PowerBuilder component itself was trivial. I simply migrated the existing application and then indicated that I wanted to create an ASP.NET target project for deployment (see Figure 1).

By default, the project doesn't include any methods of the component; you need to specify which ones you want to expose in the published Web Service (see Figure 2).

One minor difference is that a PowerBuilder component deployed to EAServer can't refer to an application object, so it doesn't have access to any of the global variables (e.g., SQLCA) that an application object creates. An ASP.NET target does have an application object, so I no longer have to create a local transaction object in the component methods. Instead I'm using SQLCA, although I still set the transaction object properties and do the connect/disconnect in the method (see Listing 1 and Listing 2).

Note that for a "true" production application where you would need to support a large numbers of users simultaneously you would want to use an ADO.NET driver rather than the native driver I'm using here. That's because ADO.NET automatically uses OLEDB session pooling. Therefore, as long as your connection parameters are identical for each connection attempt, you would automatically be provided connection-pooling support. See "Pooling in the Microsoft Data Access Components" (http://msdn2.microsoft.com/en-us/library/ms810829.aspx) for more information.

Once you've deployed the Web Service, the "Run" option will take you directly to the ASP.NET Web Service page (see Figure 3). Note that if you add "?WSDL" to the end of the URL for the Web Service page, you'll get the WSDL that describes the Web Service. The links on the page for each of the methods will take you to a page that you can use to test the Web Service if you're accessing the Web Service from the machine it's deployed to.

Creating the Calling Web Pages
Now that we have our ASP.NET Web Service, it's time to call it and render the results. Since the service is ASP.NET-based, I wanted to use ASP.NET to handle that as well. Fortunately, ASP.NET includes an XML Web server control that makes this very simple. For more information on the control see "HOW TO: Display an XML Document in ASP.NET by Using the XML Web Server Control" (http://support.microsoft.com/kb/315906).

As a result, the ASPX files that we use to show the search results or individual messages are almost identical and rather small (see Listing 3 and Listing 4). They simply embed the control with an instruction to do the processing on the server and leave the rest to the code in the code-behind file.

The code-behind files are also somewhat similar and fairly small (see Listing 5 and Listing 6). The parameters to the page are pulled off and passed to an instance of the Web Service reference. The result is pulled into a string variable that is then loaded into an XmlDocument object. An XslTransform object is also created and pointed to the location of an XSLT file that directs the conversion of the XML to HTML. The XmlDocument and XslTransform objects are then associated with the XML Web server control that performs the transformation of the HTML page. In the case of the search page, I also created an XsltArgumentList object based on the page arguments and then associated that with the XML Web server control as well. That's because the XSLT file will be using those to create hyperlinks in the resulting HTML page.

Creating the XSLT Files
The XSLT files used to direct the transformation of the XML to HTML are in Listing 7 and Listing 8. Samples of the resulting HTML pages are shown in Figure 4 and Figure 5. If you're familiar with Google Groups, you'll notice that I've patterned the layout after the way that they display search results and individual messages, although Google Groups has since significantly altered the way they display individual messages.

The XSLT file for displaying the message is very straightforward. Most of the data is formatted into a simple table. The message text itself is inserting into a <PRE> tag that's used in HTML to display pre-formatted text.

If there's any complicated coding in this entire implementation, it's actually in the XSLT file used to process the search results. Let's look at it in a bit more detail.

The first thing you'll notice is a set of xsl:param tags that are used to obtain the arguments that were passed into the stylesheet through the XsltArguments object. Then there's an xsl:variable called "count" that determines how many rows are in the result set by counting the number of "search_row" tags in the XML file.

If the count is greater than zero, two xsl:call-template tags are processed. The xsl:call-template tag is the XSLT equivalent of a function or subroutine call. There are additional templates embedded in this same XSLT file that are called via the tag at that point in the parent template. The first template ("links") displays links that point to other result pages for the search and the second ("rows") displays the current set of results.