DBMS, July 1996
The long-awaited PowerBuilder 5.0 is finally within the grasp of client/server developers who consider PowerBuilder a career, not just a tool. As other tools continue to flood the market, PowerBuilder shows us that this old dog definitely has some new tricks. Or, are these just old tricks performed by a new dog?
This month I take a quick tour through all the new features of PowerBuilder 5.0. I'll concentrate on the most interesting of its new features: application partitioning. At press time, 5.0 had not hit the streets, so I had to settle for the late beta.
With this release, Powersoft clearly keeps up with the competition. PowerBuilder 5.0 provides many of the same features found in other popular, specialized client/server tools such as SQLWindows, Visual Basic, and Delphi. However, PowerBuilder does it with legions of developers.
Starting from the top, you'll find that PowerBuilder 5.0 provides a better application deployment mechanism, which was a weakness in the previous release. Now the code is compiled using Watcom compiler technology that provides near-native application execution.
PowerBuilder 5.0 is also Win32-ready, with 32-bit native support for both Windows 95 and Windows NT (both Intel and Alpha versions). (See Figure 1, page 30.) Versions for Unix and the Macintosh are not yet available. For those who have yet to upgrade to the Microsoft way of thinking, PowerBuilder 5.0 can still generate Win16 applications for Windows 3.11 clients.
The ODBC interface in 5.0 is new and improved, and it now provides clustered indexes and a number of connection options. For instance, ODBC includes blocked fetch that supports 100 for a table list, 25 for a column list, and 10 for an index list. This enables PowerBuilder to better utilize the ODBC API and thus provide faster database reads for applications.
PowerBuilder 5.0 is more object-oriented than ever, with new support for function overloading. Now you can create user-defined functions that are dependent upon the objects supplied to it. This lets you dig deeper into the object-oriented development model, doing more with fewer lines of code. With each release, PowerBuilder is getting closer to the concept of true object-oriented development, now found in only a few client/server tools, such as those based on Smalltalk.
PowerBuilder's ObjectCycle is a helpful tool for team development. ObjectCycle provides a server-based object management facility with versioning, labeling, and reporting functions for a workgroup environment. This will put a dent in Intersolv's PVCS PowerBuilder market, which makes up the most popular configuration management tools for PowerBuilder development.
At long last, PowerBuilder supports OLE custom control (OCX) components for integration as objects inside the PowerBuilder 5.0 development environment. PowerBuilder provides a Component Gallery, which contains a number of OCX files for use inside PowerBuilder 5.0. This lets you take advantage of the hundreds of OCX components on the market today, doing everything from 3270 emulation from within an application to providing a simple calculator or advanced financial calculations. As the market for OCXs expands, the ability to use OCXs inside of application development environments is becoming critical.
OLE automation is also a part of 5.0. You can use PowerBuilder to create OLE automation clients and servers that can work with other OLE-enabled applications, even other OLE-enabled client/server development tools such as Visual Basic and Delphi.
OLE automation provides PowerBuilder with built-in links to the Distributed Component Object Model, or DCOM (formally Network OLE), when it becomes part of Windows NT 4.0 later this year. DCOM is Microsoft's answer to distributed objects, and it will soon become the force to be reckoned with because other ORB vendors (such as those based on the Common Object Request Broker Architecture [CORBA]) are slow to work and play well with each other, and they lack tools. This OLE automation will enable PowerBuilder developers to create shared OLE automation servers directly from the tool, as well as allow PowerBuilder applications to link to many shared OLE automation servers that exist on the same machine or on remote application servers.
DCOM by its nature provides application partitioning capabilities. Multiple OLE automation servers allow developers to scale through process distribution. As I mentioned in past columns, this is hot stuff, and it will change the way we develop client/server systems in the near future. PowerBuilder is just the latest tool to jump on the OLE automation bandwagon.
OLE is not the only way PowerBuilder can offer application partitioning. PowerBuilder 5.0 includes links to commercial object request brokers (ORBs), which are traditional distributed objects. PowerBuilder 5.0 links to commercial ORBs by using DLLs that facilitate communications between the PowerBuilder application and the ORB. The DLLs let PowerBuilder (using DataWindows) encapsulate function calls to external environments. Powersoft plans to partner with commercial ORB vendors to create bundled solutions for its developers.
To link to external objects, you need only create the interface to the remote procedure using the distributed computing toolkit. Next, you compile the interface into a client stub and a server stub that allows the interface to be invoked from the client. Finally, create an external definition within the PowerBuilder environment to invoke the function interface and perform tasks such as populate DataWindows. This function may reside inside a PowerBuilder User Object.
Building a PowerBuilder system that incorporates third-party distributed objects requires that you code application-level logic with a low-level programming language such as C or C++. Thus, you have to build an application in two languages, which takes a while. This two-language procedure is a better fit for those shops with application logic that already exists within distributed objects. However, with DCOM not yet a reality, this is the only way you can create a multi-tiered open architecture without using PowerBuilder's proprietary application partitioning feature.
The key new feature that will move you to PowerBuilder 5.0 is an application partitioning tool called Distributed PowerBuilder (DPB). Like other application partitioning tools, PowerBuilder 5.0 lets you create non-visual user objects (NVUOs) that contain business rules and execute them on remote application servers. You can place these objects on any number of application servers to increase scalability and centralize application management, because the application logic resides in central locations. PowerBuilder unites rapid application development (RAD) and multi-tier computing.
Fortunately, the basics of PowerBuilder are a part of the DPB feature; thus, the implementation is familiar to developers who have used NVUOs in previous versions of PowerBuilder. PowerBuilder also hides the complexities of the underlying communications drivers from you. The proprietary middleware does all the work for you.
You should note that PowerBuilder can only communicate with remote NVUOs synchronously -- the calling process is halted until the remote processing completes. Most application partitioning tools use an asynchronous messaging system, which seems to be a better fit for multi-tiered client/server computing.
Two other limitations are platforms and communication drivers for application servers. Currently, only Windows NT 3.51 supports Named Pipes, Sockets, and the proprietary Sybase Open Client/Server. You can use Windows 95 as a server, but only with Sockets. TCP/IP is the preferred network protocol. Both of these platforms can function as clients, as can Windows 3.11. Missing from PowerBuilder 5.0 is support for high-end Unix servers, or the ability to distribute to large centralized systems such as mini and mainframe computers.
If you want to build DPB applications, you'll have to become familiar with some new concepts and processes -- even if you are the most experienced PowerBuilder developer. For instance, there are new PowerBuilder object classes that are inherited from the nonvisualobject and structure you'll find in the new powerobject class hierarchy. Like other PowerBuilder features, the library is everything. I suggest you learn the library before you begin development, rather than reinvent the wheel many times over.
PowerBuilder 5.0 introduces the concept of a PowerBuilder server application. This is just what it sounds like: an application that contains non-visual user objects (NVUOs) callable by one or several client applications. In PowerBuilder lingo, NVUOs that exist in remote application servers are known as remote objects and are accessible over a network or locally.
Building an application server is the same as building a traditional PowerBuilder application. However, you need to add a transport object to the application. It's possible to take existing PowerBuilder applications and, with a little bit of redevelopment, deploy them as application servers.
Transport objects are encapsulated inside DPB server applications, and they allow the applications to listen for client requests. When the server application encounters a request, it processes the request on behalf of the client, then returns the results to the client when complete.
Developers can run DPB server applications on the client as an option. A single application can contain a client and a server, functioning as both a client and a server for testing and debugging purposes.
I don't think this is the type of development you can RAD your way through. There is more of an emphasis on the design, whereby you build the application as much as possible from reusable components shared on the application server.
Drilling down deeper into the DPB paradigm, you'll find that application servers are made up of remote objects. Remote objects are functionally equivalent to remote procedure calls, and they support parameter passing and results processing. Remote objects encapsulate PowerScripts that define the business logic of the application. These objects can also link to DBMSs using PowerScript database commands, as well as use a non-visual version of a DataWindow called a DataStore. DataStores encapsulate database access on behalf of the object.
The client application is very similar to a traditional PowerBuilder application. However, like the transport object, the client application needs to include a Connection object. The Connection object lets the client application link to the server application and, once connected, invoke remote methods encapsulated in NVUOs as if they existed locally. The transparency of this process is the strength of the tool.
If you are a PowerBuilder 4.0 developer, and many of you are, you must be thinking about the impact of an upgrade to 5.0 on your application(s). The only way to determine this is to test your application(s) under 5.0. The following are just a few of the things you'll need to look for.
First, PowerBuilder will support the migration of 4.0 applications using a migration utility that is built into PowerBuilder 5.0. This utility will convert the objects for you, but it won't convert special features you place in your application such as DLLs. You'll have to take those sorts of application features on a case-by-case basis.
I could run a very simple 4.0 application under 5.0 without modification. When you open the application, PowerBuilder 5.0 lets you know that the application must be changed to support 5.0. When you tell PowerBuilder 5.0 to migrate your 4.0 application, it automatically reformats your objects and recompiles the application under 5.0. For my tiny 4.0 application, it took less than a minute. It was nice to see that my 4.0 application did pick up speed after the 5.0 conversion, now native in its Windows 95 environment.
If you are an existing PowerBuilder developer and you see Windows 95 or Windows NT in your near future, I recommend that you upgrade to 5.0 right now. The new application deployment feature alone is well worth the trouble it will cause to migrate your applications. Add to this its 32-bit application development capabilities, and the decision becomes clear. For those of you who still have Windows 3.11 clients, you will not realize the same benefits from 5.0. Also, I did not find the annoying bugs in this version of PowerBuilder (albeit a beta) that I did in previous releases.
What PowerBuilder does best with this release is open up its architecture to support proprietary and non-proprietary application partitioning. With PowerBuilder 5.0, you can partition an application using the forthcoming DCOM standards, commercial ORBs, or PowerBuilder's own application partitioning capabilities.
Distributed PowerBuilder is easy to use, and it lets you scale through application distribution. On the downside, it only supports Windows NT and Windows 95, and you have to hand-code the partitioning capabilities into the application. Other application partitioning tools such as Fortý and Dynasty support automatic dynamic partitioning using proprietary ORBs. Clearly, PowerBuilder 5.0 will get Powersoft into the partitioning business, and I expect great things from the company in subsequent releases. The popularity of PowerBuilder will drive many to upgrade to 5.0, and users and developers alike will see Powersoft continue its legacy with this release.