Using Plug-Ins to Rehost a Client/Server Application for Running on a Web Browser.
The Internet is still maturing in the area of business applications and development technologies. The tools market is very fragmented: De facto standards such as plug-ins, ActiveX controls, Java, and HTML are vying to become the development environment of choice for extending data-driven applications toward full Internet capability. One of these contenders -- browser plug-ins --provides a way to speed the deployment of highly functional, visually sophisticated Web applications. A new arrival, the PowerBuilder Window Plug-In, enables complete PowerBuilder applications to run within a plug-in-enabled Web browser such as Netscape Navigator (2.0 or later) or Microsoft Internet Explorer (3.0 or later).
Plug-ins can have one of three modes of operation: embedded, full-screen, or hidden. An embedded plug-in is a part of a larger HTML document, visible as a rectangular frame within a page (embedded plug-ins are specified in HTML with the EMBED tag). A full-screen plug-in is a self-contained viewer, completely filling the content area of your browser window. A hidden plug-in runs in the background. Figure 2 shows how my application uses the EMBED tag. The plug-in appears as a window on the displayed form. You interact with the window as you would any other control on an HTML form.
Figure 3 shows that the PowerBuilder runtime and PowerBuilder plug-in DLL must be installed on the client workstation in order to reference a PowerBuilder window. The plug-in-enabled browser starts my plug-in application (file name: inventory.pbd) when it is referenced by special tags in the HTML page (file name: inventory.htm) retrieved from an Internet server. PowerBuilder windows and the objects they reference are downloaded in a PBD file (PowerBuilder dynamic library) when the client requests them. Dynamic libraries are self-contained units that are similar to DLLs in that they are linked to the application at execution.
Once sent to the browser, the HTML form references the PowerBuilder child window w_inventory, which was compiled into inventory.pbd. Scripts attached to events for objects/controls on the window are executed on the client machine (that is, on the browser), as with any other PowerBuilder application. When the page (or form) is unloaded, the PowerBuilder window is closed.
Additionally, your Window Plug-In application can interface with a Distributed PowerBuilder application that may reside on another platform, such as Unix. You can now distribute PowerBuilder objects across the network for increased scalability and centralized management. The Window Plug-In exists as part of Netscape's Application Programming Interface (API). As a DLL, the Window Plug-In is called as necessary into memory, where it will stay until termination of all the applications that use its services.
Sitting in front of the client-side GUI, the kitchen's production manager selects a recipe from the list in the upper left-hand corner and types in the number of servings ("Enter Production Quantity:") in the edit box below. When the manager presses the command button ("Request Production-Scale Information") at the bottom, the data window in the center is repopulated with data retrieved from the DBMS after the quantity and units data have been converted to values appropriate to the scale requested. For example, if the basic recipe table specifies three teaspoons of sugar for four servings, and the customer requires ingredients for 16 servings, the data window will display 1/4 cup of sugar. For still larger runs, the units value might be listed as, for example, 10-pound bag. If no rescaling is required, the program retrieves the recipe information exactly as it is stored in the recipe table of the database.
Also after pressing the command button, the contents of the three-page tab control located in the upper right-hand section of the form are updated. The full-size Formula One spreadsheet (an OCX that is included in PowerBuilder 5.0 Enterprise Edition) in the first page provides seamless integration between SQL and spreadsheet data. In my application, this Excel-compatible spreadsheet gives the manager cost breakdown and other accounting information related to the order being placed. As a component, this spreadsheet requires a fraction of the resources consumed by standalone spreadsheets.
The second tab contains an invoice for the current (but not yet submitted) order for the manager to examine. The third tab contains information needed for a production run of the selected recipe. When satisfied with the details of the report, the manager presses the "Send Purchase Order" button. This last step can be modified: If, say, the invoice indicated two-day delivery when the manager required next-day delivery, the "E-Mail" button could be used to initiate a change. At the Newco DBMS, procedures (and, alternatively, triggers) query database tables that contain data on recipes, customers (the kitchens), and inventory, in addition to the accounting system of New England Food Services (Bridgeport, Conn.).
At the Newco DBMS, the client's queries are examined and the size of the requested stock is compared with current inventory levels. After a procedure examines reorder lead-times and other factors, the algorithm decides which information to send to the customer who placed the order. Moreover, a number of other Transact-SQL scripts run at the DBMS: When there is a need to replenish inventory levels, scripts use string functions to create and send email messages to vendors that the food service company's inventory department uses. When a purchase order is received by the food service company, the inventory table is credited and the accounts receivable table is debited.
Stored procedures differ from ordinary SQL statements and from batches of SQL statements in that they are precompiled. The first time you run a procedure, SQL Server's query processor analyzes it and prepares an execution plan that is ultimately stored in a system table (also known as the data dictionary). The procedure is then executed according to the stored plan -- almost instantaneously, because most of the query processing work has already been performed.
Glancing at the design of my application (as seen in Figure 3), you can see where performance gains or losses can occur: in the client workstations, at the two servers, or in any of the data communication channels that connect these nodes. What you can't see is how the scheduling of server access can also be a factor that determines system performance. If all of the clients try to connect to the Web server or to the DBMS at the same time, performance will suffer. But if you spread out these access times, the servers will be able to handle their loads much more effectively. Charging less for connections made during off-peak hours usually works.
My PowerBuilder application (inventory.pbd) is downloaded from the Web server to the Web browser. From there, it connects to the DBMS. These connections frequently involve two physically distinct data communication channels. One channel is indicated in Figure 3 by the solid lines between the Web server and the individual clients; the other channel is indicated by the dashed lines between the DBMS and the individual clients. Naturally, the two servers could run on the same workstation, but they would each compete for the resources of a single hardware platform.
Although loaded with functionality, inventory.pbd is only 75 kilobytes in size. A file of this size can be downloaded by most industrial users in just a few seconds, but users with an analog modem will wait for as long as 30 seconds. The amount of data returned to the client depends on the query selected. Other influential factors include whether the raw materials that the user has requested are available in inventory, whether the order is below a minimum level, whether the user account is in default, and whether an email message must be generated by the DBMS, on-the-fly, as part of its response to the query.
In addition to the time it takes for the .pbd file, queries, and result sets to travel through their respective data communication channels, you must also consider the application processing time of the client and server workstations. You will suffer poor performance when you run a full-featured application on anemic workstations and operating systems. On the other hand, to improve performance, you could either get along with fewer features or upgrade your computer resources.
So what's the bottom line? Do you have to go through a lengthy analysis to find out whether or not you'll be happy rehosting your present PowerBuilder application to run in a browser, across the Internet? The answer is a qualified "no." If your application already works over a WAN, you should see similar performance after modifying it to operate in this new browser-centric environment. If, on the other hand, your application currently runs over a LAN, you'll have to do your own computations to get estimates of the additional time imposed by your new data connection channel.
What if you're a PowerBuilder developer who wants to leverage PB skills and develop a brand new application to run in a Web browser? This is an extremely good reason to use the Window Plug-In, because the process involves little more than installing a few additional files. Before the plug-in, developers couldn't deploy a PowerBuilder application to run in a browser; they had to deal with HTML pages or Common Gateway Interface programming.
