WO2001067242A1

WO2001067242A1 - Computer application development and deployment

Info

Publication number: WO2001067242A1
Application number: PCT/GB2001/001063
Authority: WO
Inventors: Robert Martin Mitchell; Michael Monschau; Peter Kelly
Original assignee: Raining Data Corporation
Priority date: 2000-03-10
Filing date: 2001-03-12
Publication date: 2001-09-13
Also published as: GB0005892D0; AU3763601A

Abstract

A system for client server object orientated application design comprises means for verifying that a method configured to be executed on the client is available for client execution. If the method is available for client execution, the method may be reconfigured. Similarly, if the method is unavailable, it is configured as non client executable. The system provides efficient division of methods between a client and a server depending upon the application being designed.

Description

COMPUTER APPLICATION DEVELOPMENT AND DEPLOYMENT

FIELD OF THE INVENTION

The present invention relates to rapid development and deployment of computer applications. In particular, the invention relates to executing methods in client-server applications .

BACKGROUND OF THE INVENTION

Techniques exist for developing computer software applications and also for deploying applications, for example by publishing HTML pages over Internet Protocol on the World Wide Web. The present invention relates generally to these two fields.

Object Oriented (00) programming is well known and involves certain key concepts that will be discussed by way of background. These techniques are well known to those skilled in the art, but will be explained nonetheless for consistency of terminology when describing the embodiment of the invention later.

An object is a software bundle of related variables and methods. Software objects are often used to model real- world objects found in everyday life, and are used to represent such real world objects through the variables and methods. Variables represent the state of an object (e.g. name, colour, etc.) whereas methods represent behaviour (e.g. moving, flashing, etc.) . Variables are the principal container of data, and methods are pieces of code that perform an action when interacting with the object. Objects are created from templates known as classes. An object is said to be an instance of a class. Accordingly, an object is sometimes simply referred to as an instance.

Software objects can, therefore, model real world objects through variables and methods. In addition, software objects are used to model abstract concepts. For example, an event is a common object used in Graphical User Interface (GUI) window systems to represent the action of a user pressing a key on a keyboard.

A single object alone is not very useful and needs to interact with other objects to provide functionality of a larger program or application. Software objects interact and communicate with each other by sending messages to each other. For example, when Object A wants object B to perform one of B's methods, Object A sends a message to Object B.

A message comprises :

1. The object to whom the message is addressed

2. The name of the method to perform

3. Any parameters needed by the method

These three parts of a message provide enough information for the receiving object to perform the desired method. No other information or context is required. An object's behaviour is expressed through its methods which are supported by message passing. As a result, objects do not need to be part of the same process, or even on the same machine, to send and receive messages between each other.

To provide reusability of code, and facilitate creation of objects, the definitions of variables and methods common to objects of a certain kind are stored as a class. A class is, therefore, a blueprint that defines the variables and methods common to all objects of a certain kind. In a real world example, a particular bicycle is an object which is an instance of the class of objects known as bicycles. All bicycles have common methods and variables. To create a particular object one creates an instance of the class of objects or, in other words, one instantiates the class.

The values for instance variables are provided by each instance of the class. When instantiating the class (creating an instance of it) , an object of that type is created and the system allocates memory for the instance variables defined by the class . Then you can invoke the objects' instance methods to make it do something. Instances of the same class in general share the same instance method implementations (methods are not duplicated on a per object basis) which reside in the class itself.

In addition to instance variables and methods, classes can also define class variables and class methods. Class variables and methods can be accessed from an instance of the class, or directly from the class itself. A system has a single copy of class variables for a class, and all instances of the class share the class variables. If one object (an instance of a class) changes a class variable, then that variable changes for that class, and all objects of that class.

Object Oriented systems also allow classes to be defined in terms of other classes. This brings in the concept of superclass and subclass. Each subclass inherits variables from the superclass (e.g. mountain bikes and racing bikes have variables of speed, etc. from the superclass bicycles) and also inherits methods (e.g. braking) from the superclass. Subclasses can also have additional variables and methods in addition to those inherited from the superclass. An inheritance tree, or class hierarchy, can be as deep as needed, but in practice the depth is limited for practical reasons.

With the discussion of 00 techniques as background for consistency of terminology, a known application development system will now be described. To simplify discussion, the terminology used from now on will refer to classes and instances.

BRIEF DESCRIPTION OF A KNOWN SYSTEM

A known 00 system for application development is named 0MNIS Studio of 0MNIS Software, Inc. 0MNIS Studio 2.x is a Rapid Application Development (RAD) environment that supports 00 development as well as providing access to a full range of databases and Internet services.

The building of an application involves assembling various building blocks or components, including:

_ an executable program

_ one or more library files

_ data access modules (DAMs) for server database access

_ data files for local data access

The key parts of the application are the executable and the library files. The executable directs instances m an application and provides the Integrated Development Environment (IDE) m which to design an application. It also provides the runtime environment m which a finished application runs. The mam component m an application is the library file, and so the next part of the description will concentrate on a discussion of libraries .

The system uses many of the concepts and terms from 00 Programming, including messaging, inheritance, and code reuse

Developing an application is all about creating the right instances and implementing how these instances interact with each other and the end user. A library can contain definitions of many different types of data and GUI instances including windows, menus, toolbars, and reports The definition for each of these instances is stored m the library as a separate class. Some classes are never instantiated and simply provide templates such as file f ormats .

The system provides several tools that let you create and examine the libraries and classes in an application. The main tools that let you do this are the Browser and the Component Store .

The Browser can create libraries and classes, examine existing libraries and copy classes from one library to another. The Component Store contains templates for classes and controls (controls are defined below) . Classes are thus gathered together as libraries. To create instances of a class the relevant class is instantiated, or put another way, the class is opened.

Controls provide the user interface element of an application. Examples of controls are data entry fields, lists, and push buttons. Controls are contained in a class, and when the class is instantiated, an instance of the control is also created. Only certain types of class can contain controls. You add a control to a class using the Component Store .

Every instance has certain characteristics that define exactly how it looks and behaves. These are called its properties. Properties of an instance might include its name, type, colour, size, border style, visibility, and so on. Every library has its own set of properties, classes have their own properties, and individual instances such as controls on a window have properties as well. Some properties are common to all instances, such as name, and some are unique to a specific type of instance.

Instances also contain methods, as previously described, which are pieces of code that perform some action when you send the instance the appropriate message. For example, window classes contain a method to construct the class. In this case, when you open the window the construct method is executed which initialises the window.

Instances contain default methods, but further methods can be added that either add to the instances' s functionality or override its standard behaviour. You use the method editor to add methods to an instance. Methods contain commands that define exactly what the method does. The system has over 400 commands that do everything from opening a window, installing a menu, printing a report, to responding to events in your application.

Methods can be added to most types of class and the controls within the class. For example, you can add methods to a window and to each of the controls on the window, and you can add methods to a toolbar class and put methods behind each of its controls.

The principal data container is the variable. Most instances can contain variables but their scope and the kind of data they can contain depends on the variable type. Variables can be added to most types of class. Such class variables are visible only within that class, and their values are available to all the methods in the class. Also you can add variables to any method. These are called local variables, and are available only to the method in which they are defined. You add variables to an instance using the method editor.

An instance is what you create when you open or instantiate a class. For example, you create an instance of a window when you open a window class. When you print a report you create an instance of a report class, and _. similarly when you install a menu you create an instance of a menu class. When you open an instance of a class it inherits all the properties, methods, and variables from the class. In addition to class variables, each instance can contain instance variables; these are defined in the class using the method editor. You can create multiple instances of most types .of class, which means each instance can have its own set of instance variable values. For example, you can create multiple instances of the same window class and display different data values in each separate window instance.

A task is a runtime container for the instances in your application. Instances of any class must always be opened in a task. Since instances are owned by the tasks in which they are running, manipulating the task manipulates all instances owned by the task. In this way you can hide and show all the instances or close all the current instances belonging to a particular task.

The essential components of any 00 Programming system are the instances in that system and the messages sent to and from those instances. A message is an instruction to do something to an instance, such as open, close, print, or redraw the instance Messages are sent to and from the various instances m an application using commands and a standard notation. The notation for messages will not be described m detail here. Messages are provided, for example, to change the background colour of a window instance you would sent the $backcolor. $assιgn () message with a colour value as a parameter. As well as assigning to an instance, you can return information from an instance using messages. For example, you could find out the background colour of a window instance by returning the value of its colour property. You do this using similar notation.

Any user action that occurs m the system is reported as an event message. The key to creating an event-based application is m the methods you write to intercept or handle these events. These methods are called event handling methods and you would normally put them behind controls and windows, or place them m the tasks m your library. When the user generates an event, a message is sent describing the event. Usually this message is a simple predefined code for the event. Depending on where the event occurs it is intercepted by an event handling method. For example, if the user clicks on a field, a simple click event is generated and the event handler for the field is called The event handling method can modify the default action for the event or redirect method execution to anywhere else m your application. Alternatively, the event handler may discard the event altogether or pass it on to the next method m a series or chain. Most instances including window controls and classes, toolbar controls, and menu lines contain a default event handling method, while window classes and tasks can contain a method as a further level of control. These methods contain the code that handles events passed to the instance.

When creating a new class, instead of having to set up all its properties and methods you can derive it from an existing class. The new class is said to be a subclass of the existing class, which is in turn a superclass. In this way you can create a hierarchy of classes, each class being a subclass of the one above it in the chain. The real advantage of inheritance is that a subclass takes on or inherits all the properties, variables and methods of its superclass. And in the case of a window, menu and toolbar subclass, it inherits all the controls or menu lines of the superclass as well. This saves time and effort when you develop your application, since you can reuse the controls or menu lines from the superclass. When you make a change in the superclass, all its subclasses inherit the change automatically. In addition to its own inherited properties and methods, you can add methods and any other controls or menu lines to the subclass. You can view the inheritance structure for all the classes in your library using the Inheritance Tree.

The description above provides an explanation of known 00 techniques in application design. The main job of application design is to create the classes that define the data structures, data entry windows, reports, menus, and other user interface elements m your application. These classes are stored m your library file You can create many different types of class m your library You can create classes either from the Browser or by dragging templates from the Component Store. The Component Store contains a number of templates and wizards that you can use to create classes Each library file contains a number of system tables and preferences that control the behaviour of your library and its contents A library has certain properties too, which you can examine and change using the Property Manager. You can create and open any number of library files and each library can contain any number of classes. In fact you may want to split your whole application into one or more libraries and store different types of classes m different libraries. A client application is, from the user's point of view, a collection of windows or forms m which they enter or view their data You define the appearance and behaviour of each window m your application as a separate window class Each window class can contain a number of controls which you can create from the Component Store.

The Component Store contains a number of window templates and wizards for you to use as a basis for your window classes You can also add your own templates to the Component Store and change the default ones

In summary, the known system provides 00 application design by allowing a designer to select GUI classes and gather them as a library of classes for instantiation as instances The mam class, from a user's point of view, is the window class. As with other classes, these can be selected and modified from a Component Store from which all classes are selected. The functionality provided by an application can thus be constructed using existing classes, such as toolbars and windows, and existing controls such as buttons, selected from a Component Store to build a library of classes. The properties, variables and methods of any such instance instantiated from a class can be configured to provide the required functionality of an application. The known system thereby provides rapid application development with re-usable code and extendable design.

The system described so far provides an excellent 00 approach to application design and deployment. Nonetheless, we have appreciated that improvements could be made .

SUMMARY OF THE INVENTION

We have appreciated a problem in client-server communications systems. Typically, a client will make many requests of a server for data, or to execute code as a method in an object oriented system. We have appreciated that improvements can be made to such communication in object oriented application design.

In particular, there is provided a "system for client- server object oriented application design comprising: means for constructing a client-server application comprising a plurality of instances each having one or more methods, and means for configuring at least one of said one or more methods such that the one or more methods are processed on the client, not the server

An embodiment preferably includes

means for testing the execution of said one or more methods on the client, and means for reconfiguring at least one of said plurality of objects such that the one or more methods are configured to be processed on said client or said server depending on said means for testing.

The embodying system also provides that the same fourth generation language is used for writing methods which are processed on the client or the server

Moreover during the design and testing of the application it is possible to quickly reconfigure one or more methods so as to measure the advantages and disadvantages of executing on the client

An advantage of the embodying system is that data traffic can be reduced as some simpler operations can be constructed as client executable BRIEF DESCRIPTION OF THE FIGURES

An embodiment of the invention will now be described, by way of example only, and with reference to the accompanying figures in which:

Figure 1 is a screen print of a component store and library of an 00 system embodying the invention;

Figure 2 is a screen print of an application designed using an 00 system embodying the invention as deployed on the Web;

Figure 3 is a screen print of a second application designed using an 00 system embodying the invention as deployed on the Web;

Figure 4 is a graphical representation of a communication- process for application designed using an 00 system embodying the invention may be achieved;

Figure 5 is a graphical representation of two ways in which connection to an application designed using an 00 system embodying the invention may be achieved;

Figure 6 shows the process of marking a method as client executable; Figure 7 shows how events are processed with client method execution; and

Figure 8 shows a specific example of client method execution.

DETAILED DESCRIPTION OF AN EMBODIMENT OF THE INVENTION

The embodiment of the invention described is based on one product of OMNIS Technology Corp, known as OMNIS™ Studio 3.0. and its Web Client component. In broad terms, this product provides Rapid Application Development and Deployment on the World Wide Web (Web for short) . In this context the Web also encompasses an Intranet running Transmission Control Protocol over Internet Protocol (TCP/IP) . The Web uses HyperText Markup Language (HTML) to publish material in a standard format . The present embodiment can work alongside HTML.

The system embodying the invention is written in C++ (itself an 00 language) and comprises, from a user's point of view, a GUI through which an application may be developed. The development of an application using the system requires either:

_ an Intel Pentium processor - based PC or compatible with Windows 95, Windows 98 or Windows NT4 or later 50 MB disk space required or a Power Macintosh with Macintosh System 8.0 or later 50 MB disk space required; _ or an Intel Pentium processor - based PC or compatible with Linux RedHat 6.0 or later Caldera 2.3 or later SuSE 6.2 or later 50 MB disk space required.

Other hardware/software combinations may be appropriate.

The system provides a package having a Component Store of classes such as types of window, toolbars or menus. As. previously described, developing an application using an 00 system involves creating the right instances and implementing how these instances interact with each other and the end user.

A library can be used to store the definitions of many different types of data and GUI classes including windows, menus, toolbars, and reports. The Component Store and library are shown in figure 1.

To design a new application, a user simply selects a graphical representation of a class from the component store and moves this to the library. The methods and properties of the class can then be altered according to the functionality required of the class using a method editor and Property Manager. These techniques are similar to those previously described in relation to the preceding brief description of a known system, and will not be repeated here.

The present system allows creation of a new type of class to facilitate deployment on the Web. This class is named the Remote Form Class. The system provides for design of remote forms that users can access and display a Web browser. A remote form is a class that contains all the necessary controls to display data and allow users to interact with an application and database via the Web. Once connected a remote form posts events to a server application, which m turn sends results back to the client. An existing 00 designed application can be adapted for Web access by adding remote forms and adding one or two components to an existing Web server and network infrastructure.

Figures 2 and 3 show examples of remote forms constructed using the system. As can be seen, the example remote forms provide access to functionality of an underlying application, such as the image catalogue of figure 2, or the bookstore of figure ^'3.

The system has two mam parts: the Client and the Server. The client is an end-user's Web browser which they use to access and view Web pages containing a Web Client. The client is embedded m an html page which turn displays the remote form(s) stored m a library located on the server.

The server side of the system comprises a Web server, and an application server, that is, an application and a runtime engine, and database. These are shown, along with the client side, figure 4.

To access an application at any time, from anywhere m the world, the user only requires a standard Web browser. The first time a user accesses the application they need to download and install the Web Client. Having installed the Web Client, the user would navigate to the appropriate page(s) on a Web site containing the application.

The Web Client is an ActiveX or Netscape plug- in that you can place in an html page . You could however use the Web Client in any development environment that supports ActiveX. On a Windows client machine, the Web Client uses the Wininet API to communicate with the web server extension via HTTP, or HTTPS if secure transmission is required. Communications between the OMNIS Web server extension and the Runtime and library is via TCP/IP.

To use an application via the Web, a user must download and install the Web Client. This is a one-time operation. When the user accesses the application in their browser, the Web Client is activated and a connection is established with the server extension on the Web server Once a connection is established, the Web Client receives the remote form class plus all the instance variable data, icon pages, font tables, etc, which it gets from the library. The Web Client instantiates the visual instance of the remote form and all its controls, and the user can now use the form. As previously described, an instance is what you create when you open or instantiate a class .

You can monitor and control what happens in the form by monitoring the events triggered by the user while using the form. For example, an event is generated in the form when the user clicks on a form field, when they select a line in a list, press a button, or tab from field to field. You can detect and respond to an event by creating an event handling method stored with the object in the remote form. When an event is triggered, it is sent from the client to the server application and the event handling method for the object is executed. The method could do anything you want, for example, it could save the data in the form to a database, or return the result of a calculation to the client. By default all events are turned off in a remote form to cut down needless traffic, but you can enable specific events for each form control.

The server side of the system comprises a Web server, a Web server extension, the runtime or executable, the application, and your data source, either a bespoke database or proprietary server database. All these various server pieces may or may not be located on the same machine, but typically they would be on the same LAN.

The system uses a stand-alone, industry- standard Web server. Web server software is available from many different third-parties, including Web servers downloaded from the Internet. The Web server manages the html pages containing the Web Client, giving access to the application. Using a search engine on the Internet, you can search for "Web server software" to find many hundreds of sources for a suitable Web server.

The Web server also requires a Web server extension, that handles communications between the client and the application. The Web server extension is a piece of software that sits on your Web server, and listens for and queues any requests from the Web Client in the user's Web browser. Similarly, it passes any results sent from the server back to the Web Client in the user's Web browser. The Web server extension is typically installed inside the cgi-bin folder of the web server.

To complete the system the server- side uses a Runtime executable, and library containing remote forms and any necessary business logic and reporting capabilities. The Runtime and your library reside on the Web Server, or a machine local to your Web server.

Remote form classes are designed as described above using an 00 development environment. You can debug or test your remote forms during development using your own Web browser; note that in this case, you do not need a Web server in order to test your remote forms . There are many types of controls you can use in your remote forms. The form controls and include pushbuttons, single and multiline edit fields, radio buttons, check boxes, sidebars, list boxes, drop lists, and combo boxes. In addition, you can use the built-in page pane control in your remote forms .

The remote forms and any necessary business logic for the system are stored in a library file. The remote forms are stored as remote form classes. In addition you create a remote task class to handle the connection to each client. A remote task is a type of class that handles the connection between a remote form instantiated on the client and the server application, and in some cases performs some server-side event handling and processing. Therefore, all remote forms require a remote task. You need to create a remote task to use in conjunction with a remote form.

A task is a runtime container for the instances in your application. Instances of any class must always be opened in a task. Since instances are owned by the tasks they are running in, manipulating the task manipulates all instances owned by the task. In this way you can hide and show all the instances or close all the current instances belonging to a particular task.

The Web Client plug- in uses communication channels supplied by the browsers, so all traffic to and from Web Client and a Web server can be secure. Security is achieved by using a secure Web server. The page hosting the Web Client control does not have to be secure, but the Web server that Web Client talks to does if security is an issue. These are shown in figure 5.

The preferred embodiment provides an extension to the system described above, and provides the ability to mark a remote form method as running on the client, not the server. Such methods can only execute a subset of the command language, mainly flow control, expression evaluation and commands for setting properties of the form and its fields. The key benefits of client executable methods are that they move processing from the server to the client, and it eliminates the communications overhead. This is at the cost of a larger client,, and a larger initial download of the form to the client. In practice it makes sense to only allow simple methods to be executed on the client. This is because the web client libraries need to be kept as small as possible and because the amount of information (such as variable values) available on the client is limited. There is a natural conflict between how much functionality to provide on the client and the size of the client. On the whole it has been decided that small size is the most important consideration, particularly since it might be important to port the web client to very thin platforms .

The present embodiment may be contrasted with other implementations which have two objects, a client object and a server object which communicate via a remote method invocation. The present embodiment has one distributed object, part of which is instantiated on the web client, and part on the application server.

The designer of the object can decide which methods are executed on the client and which on the server when the object is deployed. This allows the designer to trade off overall performance against memory on the client, both experimentally while he is developing the object and later when deploying the application depending on the circumstances of particular configurations. There are two variations to implementation. The first has the ability to distribute a single complete object across the mternet/mtranet . In this implementation, the interface is instantiated on the client, and the business logic/methods on the server. The data of the object is shared by both client and server.

In this mode, we only use RMI . Using RMI only has performance penalties on both server and client. The second variation is termed "client method execution" (opposite of RMI), and realises a great potential for optimising client and server performance. The implementation has the ability to simply flag individual methods of an object to either run on the server or the client. This is not possible with traditional objects. Traditional objects either run entirely on the server or the client, both with their own set of data and methods to maintain. If some functionality needs to be moved from one to the other, the objects require redesign and methods and possibly data need to be moved from one object to the other, and both objects need to be redistributed. With the present embodiment, the developer simply toggles the methods execution point, and distributes the modified object to the server.

The process of marking a method as client executable is shown Figure 6. A remote form method is marked as client executable by selecting the appropriate option from a context menu attaching to that method m the Omnis Studio method editor at selection step 10. The method editor then checks if all the commands contained in the method are available for execution on the client. This is provided by a checking step 12. If one or more commands cannot be executed on the client a message is displayed 14 describing the problem and the method is not marked as client executable. Otherwise, if all the commands in the method can be executed on the client, the method is marked as client executable 16. This is a reversible process, a client executable method can be marked as not executable on the client by selecting an option attaching to the same context menu in the method editor. Client executable methods can be modified using the method editor in the same way as any other methods. When modifying a client executable method the list of available commands which is displayed only includes those which can be executed on the client and the method editor prevents any other commands from being entered. The user may then select further methods if required at step 18.

Methods are stored using a private tokenised coding scheme and not as text. Marking a method as client executable involves changing a code in the stored method. Client executable method are otherwise unchanged, all commands in the methods are stored and displayed in the same way whether they are client executable or not.

When a remote form is instantiated on a web client the tokenised client executable methods are copied to the client from the server together with the rest of the class data. In order to save processing overhead the methods which are not client executable are not copied. The web client includes the facility to cache remote form information on the client machine to avoid the need to copy it from the server whenever the form is instantiated. The tokenised client executable methods are included in this cache These mechanisms ensure that all methods which need to be executed on the client are stored on the client and are always available for immediate execution.

The process of executing a method is shown Figure 7. When the user of the web client performs some action (for example, clicking a button or selecting a line of a list) this generates an event 20 which is processed by the client. When it receives such an event the web client firstly performs some initial checks 22 to determine if an event method needs to be called for this event and if so which method. If these checks are successful the client next determines 24 if this event method has been marked as client executable which case it will already be stored on the client. Since the client only has the methods which are client executable, any method which is not available on the client must be executed on the server. If the event method is not client executable the client sends a message 26 to the server containing the method call and waits for the return value. If the event method is client executable the method is executed 28 on the client. In either case the event processing is complete 30 when the method has finished executing and at that stage the web client waits for another action by the user.

Executing a method involves executing some or all of the commands contained in the method. It is recognised that partitioning an application between the server and client should be transparent, so it should not matter to the functionality of an application whether a method executes on the server or the client. For this reason the commands available on the client are a subset of these available on the server. But the commands which are provided function in essentially the same way on the client and on the server. The set of commands which can be executed on the client include:

Commands which alter the appearance or contents of the form.

Commands which evaluate an expression and store the result in a variable or display it on the form. Expressions can contain the usual arithmetic operators and a range of funct.ions .

Commands which alter the flow of control for the method. These include conditional execution and looping constructs.

Commands which cause a message to be displayed on the client computer.

Commands which allow lists of values to be created and manipulated. Commands which are used to assist in the handling of events .

'Do method' commands which cause other methods to be executed, either on the client or on the server.

The specific case of 'Do method' commands is shown in Figure 8. If the method contains a 'Do method' command this causes the current method to suspend execution 32 and the specified method 34 to be called. If that method is client executable 36 it is immediately executed 38 and the original method resumes execution upon completion of the new method 40. If the specified method is not client executable 42 a request is sent to execute the method on the server and the original method resumes execution when the result of this request is returned by the server.

Claims

1. A system for client-server object oriented application design comprising:

- means for constructing a client-server application comprising a plurality of instances each having one or more methods ; and

- means for configuring at least one of said one or more methods such that the one or more methods are processed on the client, not the server.

2. A system according to claim 1, further comprising :

- means for testing the execution of said one or more methods on the client to indicate whether said one or more methods is executable by the client; and

- means for reconfiguring said one or more methods to be processed on said client or said server depending on the indication of said means for testing.

3. A system according to claim 1 or 2 , wherein methods which are configured as client executable are written in the same fourth generation language as methods which are configured as executable.

4. A system according to claim 1,2 or 3, wherein the means for reconfiguring comprises an editor for editing a code stored in the one or more methods .

5 A system according to any preceding claim, further comprising:

- means for verifying that a method configured to be executed on the client is available for client execution; and

- means for reconfiguring said method if said method is unavailable for client execution.

6 A system according to any preceding claim, wherein the means configuring further comprising:

- means for delivering methods that are configured as client executable to a client.

7. A computer program product having stored thereon a computer program for causing a process at a server computer, m a client server system:

- to construct a client-server application comprising a plurality of instances each having one or more methods ; and

- to configure at least one of said one or more methods such that the one or more methods are processed on the client, not the server.

8 A computer program product according to claim 7, the program further causing a process at the server:

- to test the execution of said one or more methods on the client to indicate whether said one or more methods is executed correctly and efficiently on the client; and

- to reconfigure said one or more methods to be processed on said client or said server depending on the indication of sa'id means for testing.

9. A computer program product according to claim 7 or 8, wherein methods which are configured as client executable are written in the same language as methods which are configured as server executable.

10. A computer program product according to claim 7, 8 or 9 , wherein the means for reconfiguring comprises an editor for editing a code stored in the one or more methods .

11. A computer program product according to any of claims 7 to 10 further comprising a process, at the server,

- to verify that a method configured to be executed on the client is available for client execution.

12. A computer program product according to any preceding claim, wherein the means configuring further comprising :

13 A method for client-server object oriented application design comprising

- constructing a client-server application comprising a plurality of instances each having one or more methods , and

- configuring at least one of said one or more methods such that the one or more methods are processed on the client, not the server

14 A method accordmg to claim 13, further comprising

- testing the execution of said one or more methods on the client to indicate whether said one or more methods is executed correctly and efficiently by the client, and

- reconfiguring said one or more methods to be processed on said client or said server depending on the indication of said means for testing

15 A method according to claim 13 or 14, wherein methods which are configured as client executable are written m the same language as methods which are configured as server executable

16 A method according to claim 13,14 or 15, wherein the step of reconfiguring comprises editing with an editor a code stored m the one or more methods

17. A method according to any of claims 13 to 16 further comprising:

- verifying that a method configured to be executed on the client is available for client execution; and

- reconfiguring said method if said method is unavailable for client execution.

18. A method according to any of claims 13 to 17, wherein the means step of configuring further comprising:

- delivering methods that are configured as client executable to a client.

19. A method according to any of claims 13 to 18, or a system according to any of claims 1 to 6, or a computer program product according to any of claims 7 to 12, wherein the configuring comprises setting a flag.