In our belief that object technology will soon become a predominant paradigm for modeling, developing, and using true distributed client/server applications, we set forth in this article some rather straightforward approaches to achieving scalable systems of this kind. We will employ a PowerBuilder-centric case study but present concepts in general terms, where feasible.
Let's start with a description of the three-tier (distributed) system -- outlined in Figure 1 (page 86) -- upon which we have deployed a variety of partitioned applications. As shown there, the GUI components reside and execute on the client computer, along with some of the logic components. But other components reside and execute on a remote server computer. Both the client and server application components of this three-tier system of applications can access data from server databases.
This system is "under construction" in the sense that its design considers the inclusion of both elements that are shipping today and others that are anticipated in PowerBuilder 6.0 and allied products by year's end. For example, in the "PowerBuilder 6.0's New Vertical and Horizontal Support" section at the conclusion of this article, we examine how architectural changes to selected objects in the next version of PowerBuilder can effect the total response time of these applications. We also consider how we expect a new breed of server that supports all leading component models -- Sybase Inc.'s Jaguar component transaction server -- will help us provide better online transaction processing (OLTP), not just on the LAN or WAN, but over the Internet as well.
Our liberal use of Mathematica from Wolfram Research Inc. is another indication that our system is a work in progress. As shown in later sections of this article, we use this third-party tool to help create objects that are based on real-life entities and that correctly predict and analyze the behavior of the business under certain conditions. Once we have fine-tuned these mathematical models using Mathematica, we transform them into nonvisual objects (NVOs), where they become integrated into the applications. NVOs run unattended on remote computers to provide data services and business rules.
Finally, we don't want this article to become a palimpsest on object-oriented programming, TP monitors, ORBs, Web technology, and the like. (Excellent coverage of these topics is available in recent issues of DBMS, for those who need to refer to them.) Instead, we have limited our treatment of these topics to showing some ways in which a single development tool -- PowerBuilder 5.0 and later (Enterprise Edition) -- currently contributes to all of these architectures.
The company for which this system is being tested has four plants located in Chicago, Minneapolis, St. Louis, and Houston. Major warehouses are located in New York, Jacksonville, Los Angeles, Denver, and Chicago. Factory and warehouse capacity at each location is limited, and the cost of shipping finished goods from each factory to each warehouse is different (and volatile). To service the order, an algorithm that runs on one of the application servers is required to determine which factory(s) should supply which warehouse(s) in order to maximize profits (and to minimize overall company transportation costs).
The total cost is the sum of the products of the shipping costs times the number of pallets required, for each possible shipping route (from factory to warehouse). In addition, there are two sets of constraints for this problem. The first set guarantees that the warehouse needs will be met. The second set of constraints guarantees that the factories do not exceed their capacities. The solution of this linear programming problem gives the optimum (least-cost) shipping plan for the company. That is, it identifies the plant(s), warehouse(s), and common carrier(s) best suited to fill the current order. As you have seen, linear programming is a mathematical optimization technique. It enables you to choose the best strategy by comparing the "value" to the firm of various alternative uses of its resources.
Long before the deployment of the present computer system, the company's financial management team carried out this very same calculation offline using legacy computer programs. But the cost-to-benefit ratio of making the computation is now much improved. That's because the solution of this linear programming problem is also leveraged by the three-tier system itself.
Today, this algorithm runs in real time to determine which DBMS (tier 3) a given DPB application server (tier 2) should connect to once the server receives a request from a DPB application client (tier 1). The algorithm uses the data contained in the order in which it was placed at the client, as well as supporting information from plants, warehouses, and the outside shipping companies to drive the entire application.
In this scenario, the application server performs a calculation that presently uses Mathematica to determine which of the tier-3 nodes should receive this new information as primary data -- the other DBMSs will later receive it as replica data. This "preprocessing" reduces latency, the costs of data communication, and other costs associated with the subsequent replication of this data across the 10 DBMSs (four factories, five warehouses, and headquarters). Naturally, when any one of the DBMSs in question is not reachable, another layer of routing logic kicks in.
In this system, the arrival of application requests or disk I/O tasks occurs at random time intervals. Furthermore, when these requests are serviced is also a random process. Because there are costs associated with waiting in line and adding more capacity (such as adding more hardware resources to the application server or disks to the DBMS), the application developer's job is to minimize the sum of the costs of waiting and the costs of adding more capacity. Such optimization will lead to such measures as the expected number of people in line or the expected waiting time of the arrivals, both as a function of time. These measures can be used in the cost computations to determine the number and capacity of desirable service facilities.
Fortunately for most of us, reasonable queuing decisions can frequently be based on past experience or on the facts of the current situation. But there still are situations too complex for our intuition; we might desire a more accurate answer than we can expect to be supplied by intuition. In these situations, the problem can be approached by either simulation or a mathematical model procedure.
Underlying the simplified block diagrams that fill this article are the inescapable laws of physics and mathematics. So, at the very least, you must take both queuing delays and processing delays into account when you design a system of distributed objects. You can use the equation in Figure 2 (page 88) -- it's relevant whether you are implementing a two-tier or an n-tier system -- as a starting point in thinking about your system in quantitative terms. This simple equation hides the statistical nature of the real world it is meant to represent: Figure 2 suggests that when the rate that clients generate requests equals the throughput capacity of the servers (that is, when the denominator on the right-hand side of the equation equals zero), the total response time will jump well beyond the acceptable levels of users. But statistical analysis shows that the user won't necessarily experience deadlock in this situation.
For anyone who wants to find out where the real bottlenecks will be in an n-tier system under load and how to look at them in statistical terms, we wholeheartedly recommend Introduction to Client/Server Systems by Paul E. Renaud (John Wiley & Sons, 1996). That's because neglected bottlenecks can abrogate the benefits otherwise obtained from writing even the most elegant object code.
Here again, Mathematica is used to carry out the necessary computations in the measurement and analysis of our system. Later, we plan to use it to model the statistical dynamics of each of the applications that run on this system. For this purpose, DPB includes objects whose properties and methods can help you with such studies. Having said that, we caution you to remember Heisenberg's Uncertainty Principle, which states that you can't measure something without changing it in the process.
The PowerBuilder object-oriented infrastructure for enabling the core applications in this system is presented in a special sidebar to this article on the DBMS Web site. There, class (nonvisual) user objects (NVOs) will be explained. A collection of these objects interoperating at the application servers carries out, among other things, much of the functionality that was traditionally thought to require a third-party TP monitor or ORB.
We use a TP monitor built from the resources found in PowerBuilder 5.x to get our pieces of software (most of them encapsulated objects) that don't know anything about each other to act together synergistically. Placed between clients and servers, the TP monitor manages transactions, routes them across systems, load-balances their execution, and restarts them after failures.
As part and parcel of building this TP monitor, we considered both the logical and physical partitioning of our application. The logical partitioning consists of creating discrete, modular objects whose methods and properties provide the application with the necessary functionality. Nonvisual object classes are used for partitioning the business logic and TP monitor portion of our application; visual interface objects, including Powersoft's DataWindow, are also used to complete the system. As for the physical partitioning, the TP monitor's code decides where the objects shall be deployed at run time, based on its sampling of environmental conditions.
Automatic load balancing: This can be accomplished because of the built-in functions, events, and properties now available in PowerBuilder. It includes a fully documented API (ORCA), which allows for PowerBuilder Library (.PBL) manipulation. In other words, objects can be moved during runtime from one library to another and from one machine to another. In fact, our application can automatically and dynamically distribute objects based upon the load of the processors, provide the ability to repartition based upon network changes and availability of processors, and even determine where the objects should be distributed to based upon the functionality of the object.
Performance monitoring: In addition to PowerBuilder built-in functions are additional API calls that can be made of the operating system to get processor, disk, memory, and graphical device interface information for the server and client machines. This information forms the basis of TP monitor decisions in a DPB application.
Fault tolerance: Whenever an error occurs during client/server communications, the client application can trap the error and respond to the situation. In the event of an error, PowerBuilder records information about the error in the built-in Error object. The client application can access the Error object to determine what caused the failure and then respond accordingly.
A client application can handle communications errors in a number of ways. For example, if a client connects to a server and tries to invoke a method for an object that doesn't exist, the client can disconnect from the server, connect to a different server, and retry the operation. Alternatively, the client can display a message to the user and give the user the opportunity to control what happens next.
Transaction pooling: Any shared service is prone to queuing delays. Transaction pooling maximizes database throughput while also controlling the number of database connections that can be opened at one time. By establishing a transaction pool before connecting to the database, an application can reuse connections made to the same data source. When an application connects to a database without using transaction pooling, PowerBuilder physically terminates each database transaction for which a disconnect statement is issued. When transaction pooling is in effect, PowerBuilder logically terminates the database connection and commits any database changes but does not physically remove them. Instead, the database connections are kept open in the transaction pool so that they can be reused for other database operations. You can implement all of this with one line of code: You simply issue the SetTransPool function before establishing any connections to the database.
For example, SETTRANSPOOL( 30, 35, 10) specifies that up to 35 database connections will be supported through this application, and that 30 connections will be kept open once successfully connected. When the maximum number of connections has been reached, each subsequent connection request will wait for up to 10 seconds for a connection in the pool to become available. After 10 seconds, the application will return an error.
For example, some departments within the company have a wide range of client machines, including Windows, Macintosh, and Unix. Another product from Powersoft, Web.PB, enables these departments to develop client software that can run on all of these different platforms and, at the same time, use existing PowerBuilder code. And because Web.PB users need only a Web browser to obtain new releases of software on their PC, deployment-related expenses are virtually eliminated. Another motivation for the choice of the browser-based client is the pricing policy of some DBMS vendors, which favors browser over Windows-application connections. (Note: Web.PB is presently included in Powersoft's Internet Developer Toolkit, which will be integrated into the next release of PowerBuilder.)
In some other cases, however, company politics influenced the decision to use a browser front end. But for those managers who had good reason to leverage the company's rapidly growing, Web-supporting infrastructure, we frequently recommend Web.PB (see Figure 3), which runs on a Web server and makes it possible for browser-based applications to invoke the services of remote objects. Thus you can create custom server applications in PowerBuilder to provide dynamic content to HTML documents. When an HTML document, even one with Java applets, makes a call to a method of a remote object, the server application executes the business logic for the method and then returns the results of this processing to the Web browser.
You can think of Web.PB as DPB without the proxies and without the client-side run time. Web.PB is a feature enabling DPB objects to be accessed as part of an HTTP Internet/Intranet application. With support for CGI-style forms and URL-based invocation, Web.PB brings the familiarity and strength of PowerBuilder database access and PowerScript programming to bear on the task of building applications for the Internet or Intranet. Acting as a client interface to some of our DPB applications, Web.PB allows DPB user-object functions with or without parameters to be called from HTML documents, and it allows the results of the function to be returned as content to the HTML browser. Web.PB supports servers that support CGI Standard programming, and it has in-process DLL support for Microsoft Corp.'s (Redmond, WA) Information Server and Netscape Communication Corp.'s (Mountain View, CA) Commerce Server.
To see a working example of Web.PB running a DPB application over the Web, visit www.pbtest.powersoft.com. As you will see, Powersoft has a number of overlapping approaches to delivering distributed applications. Some enable you to have thin, others medium or fat client sides.
As shown in Figure 4, different programmable object models -- PowerBuilder, OLE server, and (after the addition of the appropriate third-party products) CORBA server -- are all available to (indeed, required by some applications in) this PowerBuilder-centric system. Each of these objects is essentially a black box that performs a specific function.
Microsoft's COM/OLE is the de facto object standard; OMG's CORBA is the de jure object standard, and PowerBuilder's NVOs are a proprietary construct. Today, most OLE environments are found on the desktop; most CORBA environments are on Unix-based servers. NVOs run on Intel, Mac, and Unix (Solaris today, and possibly HP and AIX in the future).
Let's take a very brief look first at each of these object models and then the bases for our choosing specific products to create applications with them.
PowerBuilder employs a proprietary application partitioning scheme. Its class (nonvisual) objects are typically used to encapsulate some business logic that you want to make available in your application. They can be further categorized into standard, custom, or C++ objects. NVOs can be extended by inheritance. As shown in Figure 4, they can also be used to generate OLE automation server objects, which, in contrast, can not be extended by inheritance. (Note: Although the code in an automation server -- or any COM object, for that matter -- can't be reused through implementation inheritance, the added methods can be called directly.) Much more on NVOs can be found in the Web-only sidebar I mentioned previously.
The second of these object models, OLE servers, don't, of course, have to be built using PowerBuilder. Typically, they are built with other tools such as Visual Basic, C++, Java, or Delphi. (PowerBuilder also provides containers for OLE objects and visual custom controls.) These objects are accessible transparently across a network that supports DCOM. In our system, that means Windows NT 4.0 workstations and servers and Windows 95. And Software AG of North America Inc. (Reston, VA.) recently released a software developer's kit for the first Unix implementation of DCOM.
Microsoft's distributed COM (DCOM) extends the Component Object Model (COM) to support communications among objects on different computers -- on a LAN, a WAN, or even the Internet. Because DCOM is an inherently secure protocol, it can be used without being encapsulated in a virtual private network (VPN). However, VPNs such as the Windows NT 4.0 Point-to-Point Tunneling Protocol (PPTP) are sometimes used to securely tunnel private information between DCOM-based applications over the Internet. And DCOM can work well with server machines behind firewalls -- either protocol-level (port-based) or application-level (proxy server) filters.
The third model, the Common Object Request Broker Architecture (CORBA) set forth by the Object Management Group (OMG), also combines distributed processing with object orientation. CORBA was conceived from the outset to integrate distributed objects seamlessly in a client/server environment.
In short, this CORBA architecture consists of an Object Request Broker (ORB) that enables objects to make and receive requests and responses. Application objects interface with service objects and common facilities to achieve this communication transparently.
Apropos of our environment of heterogeneous objects, almost every CORBA ORB vendor currently offers a two-way gateway between its ORBs and COM. But performance problems in COM/CORBA translators are not well known at the moment. Until recently, each implementation was proprietary. However, in 1996, the OMG put forth a new standard. As a result, direct comparison of CORBA-COM gateways will become a little more meaningful. Many industry watchers will be testing the new products that are emerging. Stay tuned.
For the present, we have chosen Visigenic Software Inc.'s (San Mateo, Calif.) VisiBroker Object Request Broker and its promising sister product VisiBridge COM-to-CORBA bridge for our system. This ORB runs on all popular Unix platforms as well Windows NT and 95. The latest version of VisiBroker (version 3.0) incorporates CORBA 2.0 standards and utilizes the Internet Inter-ORB Protocol (IIOP). (ORBs written to the OMG's CORBA 2.0 specification can work together using IIOP, which works over TCP/IP networks.) Our decision to adopt these Visigenic products follows directly from our wish to have a system as "open" as possible: Visigenic's ORB is truly emerging as a de facto standard, having been licensed by Oracle Corp., Sybase, Netscape, and Novell Inc., among others; IBM Corp. has also declared that it plans to work closely with Visigenic to ensure that their respective ORBs interoperate. Further, VisiBroker will be incorporated in Sybase's Jaguar component transaction server (which we discuss in the next section of this article).
Available early in the third quarter of 1997, version 1.0 of VisiBridge lets a COM client application use a CORBA server. That is, with VisiBridge, ActiveX controls (such as those generated by PowerBuilder 6.0) implemented in Web pages or in Win32-PowerBuilder 5.0 applications can transparently access CORBA objects over the Net or within enterprise networks.
The VisiBridge Developer Kit lets developers create Microsoft COM object representations of CORBA-based objects. The Kit consists of a utility implemented using the familiar Microsoft wizard interface. The wizard lets developers transform object interface definitions and standard CORBA IDL files into Microsoft ActiveX Controls, which are then embedded in client-side applications. The resulting ActiveX Control objects, deployed either on the end user's client machine (a two-tier implementation) or on an intermediate server (a three-tier implementation), actually contain CORBA client stubs representing the CORBA objects. The VisiBroker object request broker runtime software, also resident on that client machine or intermediate server (depending on the deployment), then shuttles the object request via IIOP to the requested CORBA object.
Deployed in a three-tier fashion on an intermediate DCOM server running on a Windows NT 4.0 system, VisiBridge bridges DCOM with the CORBA environment. The advantage of this configuration is centralized control and administration of the ActiveX Control objects on the standalone DCOM server.
The results of a recent survey by the Standish Group International of 430 IT managers at Fortune 1,000 companies help give this last topic some perspective. According to the survey, 41 percent of the managers interviewed were considering the use of a CORBA object request broker and Distributed Component Object Model (DCOM) together throughout their organizations.
With PowerBuilder 6.0, shared objects will allow for greater flexibility in sharing session information. Each client still starts a session on the server. (Each session defines a thread.) However, if an object has been started and designated as a shared object (using SharedObjectRegister), other client sessions on the server have access to the object. There must be a "proxy" of the object in the client session that is a pointer to the actual shared object (the SharedObjectGet creates the pointer to the object).
Shared objects will improve existing applications: Fewer hits on databases, reduced network traffic required to share common data, and so on. At present, we are planning for new (extended) applications that include chat and whiteboarding applications for collaborative (workgroup) activities around these shared objects.
As we mentioned earlier, PowerBuilder 5.x supports asynchronous DBMS connections but not, currently, asynchronous processing. Thus a DPB client must wait until a call is complete to continue processing. And the DPB server object remains dormant between client calls.
Asynchronous processing in the next release will eliminate these shortcomings and thereby greatly improve performance in some applications. In this "Fire-and-Forget" model, successive calls will be queued on the server, where processing will continue until the queue is drained.
The next release will include "client-side" events, which will enable servers to send messages and data to clients as well as providing a general method of signaling between client and server. Here's how these events work: A proxy object on the client is a copy of the "real" object on the server that must have external events defined. From the client, you call a function to set the event handler for the object, then make your request for processing to the object on the server. When the server is finished processing, it returns an event to the calling object; the calling object checks for the presence of an event handler and passes the event to it. Another very significant enhancement in the next release will be ActiveX support to enable PowerBuilder applications to be deployed as ActiveXs in environments such as Microsoft Internet Explorer. Finally, the DataWindow's HTML generation capacity is being enhanced to make it even more flexible when it comes to the implementation of Web application servers. Although the actual details of these new features won't be known for sure until the actual release of PowerBuilder 6.0, there will likely be some restrictions.
A substantial portion of this article has dealt with extending the reach of native PowerBuilder through connections to CORBA and COM servers as well as through connections to application servers. To overcome the limitations of existing systems (ORBs, TP monitors, and Web application servers) and address the need for a middle tier that is both scalable and easy to use at the enterprise level, a new class of system software is emerging: transaction servers. This nascent technology combines many of the features of ORBs and TP monitors with component-based development, and it performs business transactions over the Internet, Intranet, Extranet, or traditional corporate network. The first transaction servers to become available are the Microsoft Transaction Server and Sybase's Jaguar component transaction server (CTS).
We will migrate to the later, more open platform required by our polyglot system: Jaguar CTS supports all leading component models, including ActiveX, JavaBeans, C++, and CORBA, in addition to PowerBuilder applications; it runs on NT and major Unix platforms. In addition, a Jaguar CTS server can "talk" to multiple protocols simultaneously and even combine different protocols within a single session. This enables Jaguar CTS to support standard protocols (such as HTTP and CORBA's IIOP) as well as stream result sets via Sybase's high-speed Tabular Data Stream (TDS). Adding further to its flexibility, CTS not only supports the Microsoft Transaction Server but also works with the leading firewalls (and provides HTTP tunneling for the others). Note: In beta at this time, Jaguar CTS is scheduled for release in the third quarter of 1997.
Throughout this article, our primary focus has been on the application, but much more could have been said about the operating system and hardware platforms. For example, directories will be essential to distributed architectures, because most software objects live on networks rather than on specific servers. To that end, Windows NT 5.0's directory and Novell's NDS will become increasingly more important. To handle the extra load of distributed objects, operating systems need scalability. In the near term, clustering, more than the increasing use of 64-bit operating systems, will provide the needed increase in horsepower. But a future in which operating systems written in 64-bit code are ubiquitous is not so hard to imagine. Today, Microsoft is developing a version of NT to run on Intel Corp.'s 64-bit Merced processor, which is due for release next year. (Preliminary claims indicate that the Merced processor will offer as much as 15 times the performance of current processors while maintaining compatibility with existing code.)
To support the Internet backbone, most server operating system vendors are now embedding Web servers and Java support into their products. Java carries software abstraction to the next level because it abstracts everything below the virtual machine. It's designed for a world in which the operating system and CPU are interchangeable parts that can be replaced without affecting applications.
Distributed objects have been around for a while, but they have remained unutilized in many quarters until now. However, beginning in the coming year, you will begin to see the emergence of an industrywide deployment of the kind of infrastructure that objects need for widespread acceptance.
