Flexible multi-platform partitioning for computer applications

What is claimed is:

1. A method of using a computer to design an application program to be executed on at least two interconnected computers, selected from at least two classes of computers, said method comprising

selecting a first class of computers comprising a first plurality of computers, each of distinct types,

selecting a second class of computers comprising a second plurality of computers, each of distinct types, any one of said second plurality of computers interconnectable with arty one of said first plurality of computers, and

preparing a logical application definition for an application program, said logical application definition comprising

defining a first service object,

defining a second service object, and

defining a third service object, such that each of said first second and third service objects can communicate with at least one of the other said service objects,

said first service object capable of execution on substantially any one of said first plurality of computers,

said second service object capable of execution on substantially any one of said second plurality of computers,

said third service object capable of execution on substantially any one of said first plurality of computers and also capable of execution on substantially any one of said second plurality of computers,

but without selecting, at the time of preparing the logical application definition,

a specific one of said first plurality of computers on which to execute said first service object,

a specific one of said second plurality of computers on which to execute said second service object, or

a specific one of said first plurality of computers or a specific one of said second plurality of computers on which to execute said third service object.

2. A method of loading an application program comprising designing an application program using the method of claim 1 and further comprising

providing a heterogeneous environment in which said application can execute, said heterogeneous environment comprising a first computer selected from said first class of computers and a second computer selected from said second class of computers, said second computer interconnected with said first computer, said second computer of a different type than said first computer,

selecting said heterogeneous environment,

loading said first service object on said first computer,

loading said second service object on said second computer, and

loading said third service object on said first computer.

3. A method of executing an application program comprising loading an application program using the method of claim 2 and further comprising executing each of said first, second and third service objects to execute said application program.

4. The method of claim 1 of designing an application program further comprising defining a first means for message transfer for passing a message to transfer information between said first service object and said second service object.

5. The method of claim 1 of designing an application program further comprising defining a first service object request broker, capable of execution on substantially any one of said second plurality of computers, connectable to and in communication with said first service object for relaying communications to and from said first service object.

6. The method of claim 5 of designing an application program further comprising defining a second service object request broker, capable of execution on substantially any one of said first plurality of computers, connectable to and in communication with said second service object for relaying communications to and from said second service object.

7. The method of claim 6 of designing an application program further comprising defining a second means for message transfer for passing a first message from said second or said third service object to said first service object request broker, then forwarding a second, corresponding message to said first service object.

8. The method of claim 7 of designing an application program further comprising defining a means for asynchronously passing a message from one of said second or third service objects to said first service object by sending a message to said first service object request broker, storing said message, then forwarding said message to said first service object.

9. The method of claim 8 of designing an application program further comprising defining said first, second and third service object request brokers and communications between respective ones of said first, second and third service objects and said first, second and third service object request brokers as needed to allow said application program to rim as if each of said first, second and third service objects were in a single physical address space.

10. The method of claim 1 of designing an application program wherein said first class of computers supports a user interface.

11. The method of claim 1 of designing an application program wherein said first class of computers comprises one or more computers selected from the group consisting of a workstation, a personal computer, a laptop computer, a palmtop computer and a personal digital assistant.

12. The method of claim 1 of designing an application program wherein a first computer in said second class of computers comprises a server.

13. The method of claim 11 of designing an application program wherein said second class of computers comprises one or more computers selected from the group consisting of a mainframe, a minicomputer, a superminicomputer, a workstation and a personal computer.

14. A method of loading an application program on interconnected computers selected from at least two classes of computers, said method comprising

selecting a first class of computers comprising a first plurality of computers, each of distinct types,

selecting a second class of computers comprising a second plurality of computers, each of distinct types, any one of said second plurality of computers interconnectable with any one of said first plurality of computers, and

preparing a logical application definition for an .application program, said logical application definition comprising

a first service object,

a second service object, and

a third service object, such that each of said first, second and third service objects can communicate with at least one of the other said service objects,

said first service object capable of execution on substantially any one of said first plurality of computers,

said second service object capable of execution on substantially any one of said second plurality of computers,

said third service object capable of execution on substantially any one of said first plurality of computers and also capable of execution on substantially any one of said second plurality of computers, but without selecting, at the time of preparing the logical application definition,

a specific one of said first plurality of computers on which to execute said first service object,

a specific one of said second plurality of computers on which to execute said second service object, or

a specific one of said first plurality of computers or a specific one of said second plurality of computers on which to execute said third service object,

then providing a plurality of heterogeneous environments in each of which said application can execute independently,

each heterogeneous environment comprising

a first computer for said heterogeneous environment, selected from said first plurality of computers and

a second computer for said heterogeneous environment, selected from said second plurality of computers and interconnected with said first computer for said heterogeneous environment,

selecting a first heterogeneous environment of said plurality of heterogeneous environments,

loading said first service object on said first computer of said first heterogeneous environment,

loading said second service object on said second computer of said first heterogeneous environment, and

selectively loading said third service object on one of said first computer or said second computer of said first heterogeneous environment, and

selecting a second heterogeneous environment of said plurality of heterogeneous environments,

loading said first service object on said first computer of said second heterogeneous environment,

loading said second service object on said second computer of said second heterogeneous environment, and

selectively loading said third service object on one of said first computer or said second computer of said second heterogeneous environment, independent of the selective loading of the third service object in said first heterogeneous environment.

15. The method of claim 14 of executing an application program further comprising loading said third service object on said first computer of said and, for each other object, selecting the other object for execution on one of said first heterogeneous environment.

16. The method of claim 15 of executing an application program further comprising moving said third service object from said first computer to said second computer of said first heterogeneous environment.

17. The method of claim 14 of executing an application program further comprising selecting said third service object to execute on said first computer in said first heterogeneous environment and selecting said third service object to execute on said second computer in said second heterogeneous environment without changing the overall operation of said application program in said first compared to said second heterogeneous environments.

18. The method of claim 3 of executing an application program further comprising replicating said third service object as a duplicate third service object and loading said duplicate third service object for execution on said second computer.

19. The method of claim 3 of executing an application program further comprising executing both said third service object and said duplicate third service object to provide load balancing.

20. The method of claim 3 of executing an application program further comprising using said third service object and said duplicate third service object to provide fault tolerance.

21. The method of claim 1 of designing an application program wherein said first and said second computers are respectively a first CPU and a second CPU tightly coupled to said first CPU.

22. The method of claim 1 of designing an application program wherein said first computer is a client and said second computer is a server.

23. The method of claim 1 of designing an application program wherein said first computer is a first server and said second computer is a second server.

24. The method of claim 3 of executing an application program further comprising deactivating said third service object after said duplicate third service object begins execution.

25. The method of claim 3 of executing an application program further comprising moving said third service object from said first computer to said second computer.

26. The method of claim 3 of executing an application program further comprising replicating said third service object on said second computer.

27. A method of loading an application program comprising

designing an application program using the method of claim 1 and further comprising

providing a heterogeneous environment in which said application can execute, said heterogeneous environment comprising a first computer selected from said first class of computers and a second computer selected from said second class of computers, said second computer interconnected with said first computer, said second computer of a different type than said first computer,

selecting said heterogeneous environment,

loading said first service object on said first computer,

loading said second service object on said second computer, and

selectively loading said third service object on one of either said first computer or said second computer.

28. A method of executing an application program comprising loading an application program using the method of claim 31 and further comprising

executing each of said first, second and third service objects to execute said application program.

29. The method of claim 1 of designing an application program further comprising defining a third service object request broker, capable of execution on substantially any one of said first plurality of computers and also capable of execution on substantially any one of said second plurality of computers, said third object request broker connectable to and in communication with said third service object for relaying communications to and from said third service object.

30. A method of executing an application program comprising loading an application program using the method of claim 14 and further comprising

executing each of said first, second and third service objects to execute said application program in said first heterogeneous environment.

31. A method of executing an application program comprising loading an application program using the method of claim 14 and further comprising

executing each of said first, second and third service objects to execute said application program in said second heterogeneous environment.

32. A method of using a computer to execute an application program on at least two interconnected computers, selected from at least two classes of computers, said method comprising

selecting a first class of computers comprising a first plurality of computers, each of distinct types,

selecting a second class of computers comprising a second plurality of computers, each of distinct types, any one of said second plurality of computers interconnectable with any one of said first plurality of computers, and

preparing a logical application definition for an application program, said logical application definition comprising

defining a first service object,

defining a second service object, and

defining a third service object, such that each of said first, second and third service objects can communicate with at least one of the other said service objects,

said first service object capable of execution on substantially any one of said first plurality of computers,

said second service object capable of execution on substantially any one of said second plurality of computers,

said third service object capable of execution on substantially any one of said first plurality of computers and also capable of execution on substantially any one of said second plurality of computers,

but without selecting, at the time of preparing the logical application definition,

a specific one of said first plurality of computers on which to execute said first service object,

a specific one of said second plurality of computers on which to execute said second service object, or

a specific one of said first plurality of computers or a specific one of said second plurality of computers on which to execute said third service object,

providing a heterogeneous environment in which said application can execute, said heterogeneous environment comprising a first computer selected from said first class of computers and a second computer selected from said second class of computers, said second computer interconnected with said first computer, said second computer of a different type than said first computer,

selecting said heterogeneous environment,

loading said first service object on said first computer,

loading said second service object on said second computer, and

loading said third service object on said first computer,

then executing each of said first, second and third service objects to execute said application program.

33. The method of claim 32 of executing an application program further comprising moving said third service object from said first computer to said second computer.

34. The method of claim 32 of executing an application program further comprising replicating said third service object on said second computer.

35. The method of claim 32 of executing an application program further comprising

not loading said third service object on said first computer, but instead

selectively loading said third service object on one of either said first computer or said second computer.

36. The method of claim 32 of executing an application program wherein said first class of computers comprises one or more computers selected from the group consisting of a workstation, a personal computer, a laptop computer, a palmtop computer and a personal digital assistant.

37. The method of claim 32 of executing an application program wherein said second class of computers comprises one or more computers selected from the group consisting of a mainframe, a minicomputer, a superminicomputer, a workstation and a personal computer.

38. The method of claim 32 of executing an application program wherein said first computer is a client and said second computer is a server.

39. The method of claim 32 of executing an application program further comprising defining a first means for message transfer for passing a message to transfer information between said first service object and said second service object.

40. The method of claim 39 of executing an application program further comprising defining a first service object request broker, capable of execution on substantially any one of said second plurality of computers, connectable to and in communication with said first service object for relaying communications to and from said first service object.

41. The method of claim 40 of executing an application program further comprising defining a means for asynchronously passing a message from one of said second or third service objects to said first service object by sending a message to said first service object request broker, storing said message, then forwarding said message to said first service object.

42. A method of using a computer to execute an application program on at least two interconnected computers, selected from at least two classes of computers, said method comprising

selecting a first class of computers comprising a first plurality of computers, each of distinct types,

selecting a second class of computers comprising a second plurality of computers, each of distinct types, any one of said second plurality of computers interconnectable with any one of said first plurality of computers, and

selecting a first service object,

selecting a second service object, and

selecting a third service object, where each of said first, second and third service objects can communicate with at least one of the other said service objects,

said first service object capable of execution on substantially any one of said first plurality of computers,

said second service object capable of execution on substantially any one of said second plurality of computers,

said third service object capable of execution on substantially any one of said first plurality of computers and also capable of execution on substantially any one of said second plurality of computers,

providing a heterogeneous environment comprising a first computer selected from said first class of computers and a second computer selected from said second class of computers, said second computer interconnected with said first computer, said second computer of a different type than said first computer,

selecting said heterogeneous environment,

loading said first service object on said first computer,

loading said second service object on said second computer, and

selectively loading said third service object on one of either said first computer or said second computer,

then executing each of said first, second and third service objects to execute said application program.

43. The method of claim 42 of executing an application program further comprising moving said third service object from said first computer to said second computer.

44. The method of claim 42 of executing an application program further comprising replicating said third service object on said second computer.

45. The method of claim 42 of executing an application program further comprising loading said third service object on said first computer.

46. The method of claim 42 of executing an application program wherein said first class of computers comprises one or more computers selected from the group consisting of a workstation, a personal computer, a laptop computer, a palmtop computer and a personal digital assistant.

47. The method of claim 42 of executing an application program wherein said second class of computers comprises one or more computers selected from the group consisting of a mainframe, a minicomputer, a superminicomputer, a workstation and a personal computer.

48. The method of claim 42 of executing an application program wherein said first computer is a client and said second computer is a server.

49. The method of claim 42 of executing an application program further comprising defining a first means for message transfer for passing a message to transfer information between said first service object and said second service object.

50. The method of claim 49 of executing an application program further comprising defining a first service object request broker, capable of execution on substantially any one of said second plurality of computers, connectable to and in communication with said first service object for relaying communications to and from said first service object.

51. The method of claim 51 of executing an application program further comprising defining a means for asynchronously passing a message from one of said second or third service objects to said first service object by sending a message to said first service object request broker, storing said message, then forwarding said message to said first service object.

Description Submit all comments and votes

FIELD OF THE INVENTION

The present invention relates to methods and apparatus for partitioning objects of an object-oriented program across multiple computing devices, including real time monitoring and modification of the partitioning.

BACKGROUND OF THE INVENTION

A computer program generally consists of at least three components: a user interface; an application program; and memory or storage. Early computers used tape or card readers and printers for primary user interface. The program or application was loaded to run on the central processing unit and either memory or disc storage or both provided data storage. As the industry matured, computers were able to interact with terminals to provide another important user interface. Small computers, known as workstations, became available to provide a user interface and computing power in the same unit. With the advent of personal computers or PCs, inexpensive computers have replaced simple terminals in many computer installations.

In early computers, a program could reside only in a single computer. Large programs could be broken into segments which could be loaded, as needed, into active memory in the central processing unit. As computers became more powerful, larger programs could be run but the capacity of a single computer remained a fundamental limit for the size of a computer program.

As workstations and PCs became more prevalent, a paradigm evolved which attempted to maximize efficiency by using available processing power in a logical manner. Since many users were interfacing with larger computers through a workstation or a PC, programmers realized that functions required to operate the user interface, such as screen redrawing, video refresh, graphics generation, windowing control (size, position and overlap), and input processing (character and function key handling, interrupts, and such), logically should be handled by software which was resident on the local workstation. Following this same line of reasoning, many programs require extensive access to computer storage. A classic program of this type is a database where a series of records are stored in a special storage area. One database used by many industries is an inventory record. Another database might be for payroll or for accounts payable. Generally, a modern database is composed of a number of records stored in the systems storage area. Multiple users can use the database simultaneously, but there must be provisions to prevent two users from accessing the same record at the same time for then both would be updating old information and possibly making and storing inconsistent changes. Programmers developed server functions which controlled record access for reading or writing information, record locking and, when available memory or storage was limited, specifying media changes such as mounting or unmounting interchangeable media such as discs or tape.

Manipulating graphic information such as windows or menu selection, graphic objects and such generally requires transferring large amounts of information, especially when manipulating bitmaps. If this information must be passed over a common network shared among many computers, then the network can easily be filled with traffic moving graphic images. In a similar way, the low level commands required to select a specific storage media, move the reading heads to the correct portion of the media and pull the information from the media requires a fair amount of activity between the controller and the reading heads when all the user or program really needs is the result, typically some or all of the contents of the requested record.

This paradigm has evolved to be known as a client-server. The server, in general, provides control of and access to one or more shared resources. One useful server is a database server, discussed above. Another useful server is a file server, where the server has access to program or data or other files and can access this information upon request. A print server might store and direct print jobs to a collection of printers which are then accessible to a large number of users through simple calls to this server.

The Evolution of Client-Server

Client-server has grown rapidly with advances in database management system (DBMS) technology and particularly relational database management system (RDBMS) technology. The architectures of the leading multi-user RDBMSs provide a separation between the user-specific work of the application program and the shared data management services of the RDBMS engine. This architecture allows a single RDBMS engine to service multiple applications as well as multiple users of the same application. Structured query language (SQL) provides applications with an easy way of requesting RDBMS services while shielding applications from the details of data management (e.g., concurrency control, backup and recovery, data access strategies).

With the advent of RDBMS networking products, applications could be off loaded from the host and placed on a different machine, using SQL as the protocol to communicate between them. At first, this technology was used between two multi-tasking minicomputers, one that ran the RDBMS engine (the back end) and the other (the front end) that drove the users' dumb terminals. With the growing acceptance of the PC, it was a logical step to replace a multi-tasking front end machine with a collection of PCs, each of which ran its own copy of the front end application program. The growing popularity of the graphical user interface (GUI) has further solidified the appropriateness of client-server, since inexpensive desktop computing cycles can be used to drive the many details of the GUI.

Meanwhile, on the RDBMS server side, the technology has also advanced. RDBMS vendors now offer multi-threaded servers with improved performance and reliability. Some offer stored procedures that can speed the processing of predefined SQL queries. Many also offer gateways to translate the RDBMS vendor's SQL dialect into RDBMSs and file systems from other vendors.

Today, client-server has come to mean PCs running an application program that accesses a shared RDBMS server over a network. Client-server is gaining rapid acceptance among Fortune 1000 companies where is being used today for departmental decision support applications. These companies are very interested in extending the client-server paradigm to enterprise-wide online applications.

Monolithic Client Application Programs

Most client-server developers today accept a predefined division of computing functions between clients and servers. Referring to FIGS. 1A and 1B, with the most commonly used predefined split, clients run the application program which handles the user's display and any application processing of the data that goes into or comes out of the RDBMS. The application program passes SQL to the RDBMS interface (which also runs on the client). The RDBMS interface then ships the SQL across the network to the RDBMS server which processes the request and returns the requested data or a status message back through the RDBMS interface to the application program. According to this model, the application program is monolithic and resides entirely on the client. It is a client application program. This model is sometimes called remote data management because the database is separate from the application program. Other models for splitting functionality between clients and servers are discussed below.

There are many high level tools on the market today for building client application programs. These tools typically include a screen designer and a high level language, often called a 4GL (Fourth Generation Language), for defining application functionality. Most of these tools support rapid prototyping or the ability to build an application as an interactive process of creating a quick prototype and subsequently refining it.

Monolithic client application programs may be well suited for decision support involving a single RDBMS. Running the entire application on the client, however, may present a number of problems for more complicated applications. These problems include:

inadequate processing power on the desktop to drive the entirety of a complex application program

slow performance due to excessive network traffic

difficulty of interfacing with data sources other than the primary RDBMS and those supported by the RDBMS vendor's gateways

minimal reusability of application components among multiple applications

Cooperative Processing

Application partitioning is best understood in the larger context of cooperative processing (an umbrella term that describes the division of application functionality in a networked environment). It would be incorrect to assume that application partitioning is synonymous with cooperative processing. An understanding of the distinction between these terms can help to illustrate the concept of this invention. To make the distinction, it is first helpful to look at the different styles of cooperative processing as enumerated by the Gartner Group, a market research firm based in Stamford, Conn.

Gartner's classification of cooperative processing styles is based on an application model that includes three different computing functions-user presentation services, application logic, and data management. Listed below are four of the ways for dividing these functions between computers. Each represents a strategy for tackling different application problems, and each is supported by a different set of tools. Together they illustrate some of the alternatives that confront IS managers as they move from stand alone host-based environments to client-server environments.

Remote Data Management. This division of functions places the presentation services and application logic on the client, while the server performs the data management functions. The communication protocol between these components is SQL. See FIG. 2.

Remote data management is a very common model for mainstream database client-server applications where a set of users interact with a desktop application that accesses a shared relational database (RDBMS) sever. This model can operate with a character oriented user interface or a graphical user interface (GUI). Many tools are available today for building applications that utilize this model (e.g., SQL*Forms, Powerbuilder, Uniface, and other 4GLs).

Distributed Presentation. This model, often called "frontware" or "screen scraping," supports a division of functionality within the presentation portion of an application. Distributed presentation takes a traditional mainframe application driving 3270 screens and allows developers to add GUI-based presentation services that run on a PC desktop. See FIG. 3. The 3270 data stream serves as the communications protocol between machines.

Distributed presentation allows organizations to upgrade the user interface to an existing application without altering the application. Several products in the market today support this approach, and they are different products from those that support remote data management.

Distributed Data Management. This model supports a division of functionality within the data management portion of an application. With this model, data can reside on more than one computer, and a distributed data management product will coordinate access to the data wherever it may reside while preserving transparent application access. Referring to FIG. 4, the distributed database knows which tables are on each server and routes requests accordingly.

Distributed data management can be used in conjunction with remote data management where an application running on the client may access data that is distributed across more than one RDBMS server. A few of the RDBMS vendors offer distributed data management products. Applications accessing distributed data can be developed with traditional 4GL tools.

Distributed Function. This model supports application logic that resides on more than one machine. The communication mechanism may be a remote procedure call (RPC) or a more conversational communication mechanism (e.g., IBM's APPC or CPI-C). See FIG. 5.

In their report Client/Server and Cooperative Processing: A Guide for the Perplexed, 1991, Gartner Group observes: "The distributed function style is particularly powerful for complex applications that are both highly user-interactive and database I/O intensive . . . . Because the functions reside on the more relevant (local) node, the number of messages that must be sent over the network between A [the client] and B [the server] is minimal, thereby enabling relatively fast response times for complex workloads." Gartner also-observes: "Distributed function applications are inherently the most difficult cooperative processing applications to design and develop, since there are two separately compiled application programs. Developers must analyze thoroughly where each function should reside and what type of dialog must occur between the two programs."

Application partitioning, which is central to the method of this invention, is a technology that simplifies the development of applications using the distributed function model described above. The general client-server paradigm, discussed above, is based on a division of computing functions among two or more nodes in a network. By dividing up computing tasks, client-server supports a flexible and cost effective computing model that may displace traditional host-based computing as the dominant paradigm for the future. Application partitioning goes beyond traditional client-server technology and provides an approach for allocating application functionality among clients and servers.

The allocation of computing functions may present many options, each with implications for performance, control, and/or flexibility. To handle application partitioning effectively, one should consider several issues surrounding the allocation of functions across multiple platforms in the network. The overall goal is to promote more effective client-server applications that can solve emerging business problems.

SUMMARY OF THE INVENTION

The invention provides a system and a method of partitioning an application program. A development programmer defines a logical application definition for an application program by defining two or more objects as components of the application program. This selection is made without considering what specific machine environment will be used at run time.

Once the objects are defined in sufficient detail to allow the application to operate, the application administrator will identify a specific environment for the application program, including at least two interconnected computers. Each object is assigned to a partition and each partition is assigned to a target computer and loaded to allow the application program to run. The system can generate a default partitioning scheme to assist the application administrator with initial partitioning. This results in the application program being partitioned as a series of partitions, each of which is assigned to a computer among available computing resources. The original partitioning selected by the computer can be modified automatically or by a user. Modification can include moving an object from one partition to another or replicating entire partitions. The invention also includes automatic detection of performance bottlenecks in operating the application program and, where appropriate, duplicating one or more objects to run on additional computers in order to enhance throughput or increase reliability in the system.

The application program can be run easily in a new environment by assigning the specific partitions to run on available equipment. A single application program might run within the same company in a variety of different partitioning schemes, based on specific resources and needs in a specific corporate location.

As client-server evolves from a departmental to an enterprise-wide strategy, application partitioning will be a key strategy.

Application partitioning is the ability to create a unified application and subsequently break it into a set of modules that execute on different nodes in a networked environment.

Application partitioning can be an important strategy for increasing performance, control, and flexibility.

Partitioning leverages the client-server model to support a new generation of enterprise applications.

Forte was designed as a tool for developing and deploying partitioned applications.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1A and 1B illustrate a prior art monolithic client application program.

FIG. 2 illustrates a prior art remote data management model.

FIG. 3 illustrates a distributed presentation model.

FIG. 4 illustrates a distributed data management model.

FIG. 5 illustrates a distributed function model.

FIGS. 6A and 6B illustrate application partitioning.

FIG. 7 illustrates another aspect of application partitioning.

FIG. 8 illustrates processing tasks in parallel.

FIG. 9 illustrates implementing a single logical application definition in multiple configurations.

FIG. 10 illustrates implementing a single logical application definition in a mixed configuration.

FIG. 11 illustrates a representative implementation of the method for a customer service application,

FIG. 12 illustrates a representative implementation of the method for a simple manufacturing process application.

FIG. 13 illustrates a representative implementation of the method for another manufacturing application.

FIG. 14 illustrates a representative implementation of the method for a financial services application.

FIG. 15 illustrates a representative implementation of the method for a customized product order/entry application.

FIG. 16 illustrates a program development cycle using the new method.

FIGS. 17A and 17B illustrate a sample application program as a traditional procedure and as a collection of services.

FIG. 18 illustrates the new development environment architecture.

FIG. 19 illustrates distribution of service objects through partitioning.

FIG. 20 illustrates default partitioning.

FIG. 21 illustrates distributed execution.

FIG. 22 illustrates using an environment manager for monitoring the distributed application.

FIG. 23 illustrates a repartitioning interface.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

Some general definitions and a description of the overall system will assist in understanding the present invention.

Distributed Applications

A distributed application provides access to distributed machines and services through a single, integrated system. The traditional client-server application runs on only two machines, a desktop computer and a database server. However, an application program using the new method can run on any number of different machines, which may be only two machines or may be many machines.

A single application program can access any number of distributed services, including

any number of databases (on any number of distinct machines)

3GL services, such as an API to the New York stock exchange, a commercial statistical analysis package, or a 3GL application developed in-house

New services, such as an image server or coordination facility

A new application program can also provide fault tolerance and parallel processing by automatically accessing backup and load sharing machines.

Partitions

In order to distribute an application, Forte (the new method) divides it into two or more logical sections, called partitions. Each partition is an independent component,which can run on its own machine. For example, a typical end user application has a client partition, generally placed on the desktop, that provides a graphical user interface. Other partitions could include: a DBMS server that runs on a mainframe; an image server that runs on a specialized machine; a 3GL service; or other special services. In a preferred implementation, the method of the invention automatically coordinates all communication between the partitions.

A partition is made up of one or more service objects. To create a distributed application requires defining any needed service object as part of the project.

Service Objects

A Forte application program is made up of objects. Each distributed service with which the application program interacts is an object. For example, a database accessed from the application program is an object. Likewise, an existing 3GL application is an object. To interact with an object, the user or another object invokes a method on it, which essentially is just like interacting with any other object in the application program.

In a distributed application, every object has a single, fixed location. When a method is invoked on an object, it is executed on the machine on which the object is located. Normally, the object is located on the machine on which it was created. Each service object can be represented on other partitions by an object request broker, described below.

Although the application may consist of thousands of objects, only a few of these need to be at a particular location. These include:

an object that represents an existing external resource, such as a database management system or a 3GL service, that is already present on a particular machine

an object that provides a Forte service that is going to be shared by multiple users, such as an image server {or an auction manager for an auctioning function}

an object that represents a service that will be replicated to provide failover or load balancing

When an application is divided into partitions, these central services are objects that may need to be placed on specific machines.

The application programmer has the option of specifying that a selected object must be located on a specific partition by creating and naming a service object. The application programmer does not need to worry about the locations of other objects in the application program. If a service object creates other objects, these will be located on the same partition as their creator. For convenience, the rest of this application will assume that a "service object" includes related objects created by the actual service object.

A service object is simply a named object that can be referenced from any method in the application program. It is like a global variable, except that the value can be specified at compile time. When creating a service object, it is assigned a name, a class, and values for its attributes.

Once created, a service object can be used like any other object. If a user or another object invokes a method on a service object that is located on a remote machine, a request for the service object is passed through a local object request broker. A broker reproduces the interface of a corresponding service object so that when a method is invoked on the service object, all requests are captured by the local object request broker then forwarded to the actual service object for processing. Any return value and output parameters are returned through the object request broker to the original invoking object. Thus invoking a method on a service object that is located on a remote machine is completely transparent.

One special service object is a DBMS resource manager, which provides access to an existing database management system. The new resource manager provides a shell to "wrap" the existing system and intercept and translate, as necessary, all messages, requests or data sent to or from the existing system. By defining a DBMS resource manager service object, an existing database management system can be treated like any other object. The user can thus invoke methods on the new resource