Creating Interoperable .NET Resources with PowerBuilder 11
PowerBuilder 11’s .NET interoperability extends beyond the mere consumption of resources of the default .NET framework or consumption of custom developer-defined .NET resources. PowerBuilder can create powerful .NET resources itself. These PowerBuilder .NET-deployed resources may be consumed by non-PowerBuilder solutions that will benefit from PowerBuilder’s productivity. In this next segment we’ll examine how PowerBuilder deploys its components as either .NET Assemblies or as .NET Web Services.

PowerBuilder developers may create a .NET Assembly Target and Project wherein they define which methods of which PowerBuilder components (i.e., Custom Classes, Non-Visual User Objects, NVOs) will be exposed as part of the public interface of the deployed Assembly. On the “Objects” tabpage of the Assembly project, the developer may also specify an alias for the NVO that may adhere better to the developer’s team’s naming conventions (see Figure 7).

On the “General” tabpage of the Assembly project is the developer’s opportunity to define the deployed Assembly’s Namespace as well as its filename (see Figure 8).

In order to deploy the Assembly, the developer only need click on the Assembly project’s “Deploy Project” toolbar button, and the Assembly is ready to be utilized by non-PowerBuilder and PowerBuilder .NET consumers alike (see Figure 9).

If the developer chooses to use this Assembly in a Visual Studio C# WinForm client, for example, they only need to add its namespace as a reference and then invoke its public methods as they wish. The following code fragment is a C# client making requests of an NVO deployed as an Assembly with a namespace of sybase.powerbuilder.codeexamples (see Figure 10).

The technique for defining which methods of which components will constitute the public operations of a PowerBuilder .NET Web Service has a few additional features over and above the PowerBuilder .NET Assembly. In addition to being able to define the Target namespace and the Web Service name alias for the NVO, the developer also designates the Web Service’s URL and WSDL locations (see Figure 11). (It should be noted that the developer need not define, create, or deploy the WSDL itself; PowerBuilder performs that task automatically.)

The developer also defines which instance of IIS to which PowerBuilder will deploy the service... (see Figure 12).

... as well as the virtual directory name for the service in the IIS repository... (see Figure 13).

After clicking on the “Deploy Project” toolbar button, the .NET Web Service and its PowerBuilder implementation are available to any Web Service consumer. In the following figures, note the addition of the PowerBuilder Web Service as a Web Reference to the VB .NET client as well as the code fragment that invokes one of the Web Service’s operations (see Figures 14 and 15).

As a last example for this article, we’ll return to the PowerBuilder .NET Web Service Target and Project, and we’ll click on the “Run Project” toolbar button (see Figure 16). Note the “.NET Web Service Test Page” that opens in the browser instance (see Figure 17). Click on the Web Service’s test URL link (see Figure 18). Click on one of the operations’ hyperlink to open that operation’s test page (see Figure 19). Click on the “Invoke” button, supplying any parameter values that are required (see Figure 20). Note the return value of the Web Service that is displayed in the subsequent browser instance.

A few words now about productivity: PowerBuilder has automatically created a .NET Web Service test client for you. What if this is the first PowerBuilder .NET Web Service you’ve created, let alone the first Web Service you ever developed? If this test failed, there was no need to wonder if the error lay in the first Web Service client you ever developed. No need to waste time there because you’re using PowerBuilder. What if this service is one of many in an aggregate/composite service in a service-oriented architecture (SOA) for which you merely needed test harnesses? No need to waste time there because you’re using PowerBuilder. In fact, this is PowerBuilder yet again doing what it’s done best since the inception of client/server...insulating you from the complexity, the tedium, the time-consuming aspects of Windows application development...even for .NET...even for distributed .NET. This level of productivity allows you to get on with the difficult tasks...architecture, messaging, the identification, definition, and encapsulation of business rules. You take care of the hard stuff. We’ll take care of the data.

In closing, let’s assume you’re even going after the current brass ring on the IT merry-go-round...service-oriented architecture. Interoperability is supposed to let you interchangeably choose the right tool, the right component, for the job at hand. The last reason for which you want your first pilot SOA project to fail is that your team spent too much time coding for data-related tasks. The whole point to SOA is that the implementation, the language of the code of your services, is immaterial. If in fact you have any heavy lifting that needs to be done in the way of data access, data manipulation, and data persistence, why not use the implementation that takes the least amount of code, the least amount of time to accomplish these tasks? Using PowerBuilder, you can watch .NET grow, watch AJAX continue its journey to prominence, even watch J2EE maintain its place in the industry...and bypass much of their learning curves. PowerBuilder continues to enable you to remain the most productive developer on the block, and continues to make your life easy journeying into any profitable future.

Resources

• Download a PowerBuilder 11 evaluation copy.
  
• View PowerBuilder 11 videos.
  
• For more information on PowerBuilder. 

•   •   •

This article has been reprinted with permission from the ISUG Journal .