HK1112082B - Method for distributing computing between server and client and distributed computer systems - Google Patents

Abstract

A method and system for use in running a display-based computer application, the computer application comprising a plurality of application segments, where computing is distributed between a server and a client computer. The method comprises the steps of providing a generic client engine (20) to the client computer, the client engine comprising an application manager (24), one or more display managers (22), and one or more load managers (26), providing a collection of individual application subset definition files (18), each relating to one of said application segments, wherein, on receipt of successive application subset definition files from the server, the client recursively transforms to provide the respective application segments. The invention has broad utility in a wide variety of display-based computer applications, particularly in wireless applications.

Description

Method for distributing computation between server and client and distributed computer system

Technical Field

The present invention relates to the field of computer operating environments. In particular, the invention relates to a method of distributing computing between a server and a client, which can be used to provide Java applications, e.g. window-based computer applications, for a strongly displayed environment. The invention is particularly applicable to wireless applications.

Background

Before the advent or adoption of the world wide web or internet, the development of sophisticated client-server applications was typically undertaken by highly skilled software developers. With the introduction of the internet, as well as open standards such as HTML (hypertext markup language) and numerous tools available to web page developers, at least at the client side, such high level skills have become unnecessary. In the world of the world Wide Web, graphic artists and other participants can easily build the client-side of web sites or entry-level web-based applications, and software engineers and developers transition into the role of designing and developing server-side business logic elements and structures.

Thus, the current model is to develop relatively low cost resources on the client side of the internet to provide content and more expensive professional software engineers who design and develop server-side components. Recently, many problems have become apparent, especially as companies and organizations strive to migrate large-scale enterprise applications to the internet. These problems include poor performance (especially in low bandwidth locations) and lack of robustness at the client end (due to the inherent inefficiency of HTML as an application markup language).

With respect to the use of HTML, the ability to create "window-type" or strongly multi-display GUI applications (especially with dense component layout) is often very limited. In addition, the lack of inherent browser-based client-side intelligence tends to impose a large portion of the processing activity on the server, resulting in a very high level of browser-client-web-server interaction, especially when compared to the client-server predecessor. This may lead to real problems in low bandwidth environments.

HTML was designed with document publishing in mind, and thus, HTML applications severely lack the user interface functionality (multi-window, drag-and-drop capabilities, spreadsheet features, etc.) of traditional client-server applications. Thus, in general, HTML applications require a new page to be provided each time a user interacts, each page occupying a large footprint (footprint). This all brings about a serious disadvantage in terms of user productivity. Adding client-side scripting languages such as Java Script and ActiveX helps transfer some server-side processing to the client, but does not solve the layout problem around the Document Object Model (DOM), where HTML remains the layout backbone. Furthermore, data transfers between browser-based clients and web servers are not compressed, resulting in data transfer requirements that are much faster than client-server predecessors (again, a problem in low bandwidth environments).

Many of the disadvantages mentioned above, and in particular the amount of information transfer between the web server and the client, involve the need to reload the entire client, including the layout information of all clients, at each service request. Of course, HTML is essentially a single display model compared to traditional multi-display client-server applications.

The drawbacks discussed above may be particularly serious in an internet-based wireless environment due to the necessary resource limitations in terms of memory, bandwidth and operating/file system.

In the conventional thin client development model, each set of main classes and window-specific classes is different for each subset of applications. Each subset must be developed and tested separately and then loaded separately. This may lead to high bandwidth requirements or poor performance as the total commercial application requires many different application subsets. The more display parts or windows in the application subset (with associated business logic and event handling code for each part or window), the larger the overall size of the particular client.

Some recent developments have improved this situation. However, the development of web-based client-side Java-based applications still tends to include substantially fat clients, which become increasingly fat as new functionality and features continue to be added. This shifts the use of complex client-side Java-based applications to the high bandwidth environment domain.

The present invention seeks to address at least some of the problems mentioned above.

Disclosure of Invention

According to the present invention in a first aspect there is provided a method for running a display-based computer application, the application comprising a plurality of application segments, involving the distribution of computing between a server on a server computer and a client on a client computer, the server computer and the client computer being operatively interconnected by a computer network, the method comprising the steps of:

providing a general client engine to a client computer, the client engine comprising an application manager, one or more display managers, and one or more load managers;

providing a collection (collection) of respective application subset definition files, each of said respective application subset definition files being associated with one of said application segments;

wherein upon receiving successive application subset definition files from the server, the client recursively transforms to provide corresponding application segments.

The application subset definition file may define components or layout features within one or more display areas (e.g., windows) associated with the respective program segment. Preferably, the application subset definition file defines only information about components or layout features to be added or removed between successive program segments.

In a further aspect, the invention provides a computer program embodied on a computer readable medium for carrying out the above method.

Thus, the method of the present invention can provide a business solution containing a set of program segments through a generic client engine and respective application subset definition files. To run a business solution, the client engine is loaded or installed only once and then resides on the client. The client can then transform itself using an application subset definition file that maintains state information between client-server requests/responses, which definition file is used to continually update the client.

The generic client engine of the present invention is referred to herein as a "Smart client" due to its ability to recursively transform the subsets of applications that it itself provides together to form the complete business application. This is in contrast to prior art "thin client" solutions, which assemble business applications from separately downloadable components each having its own application management logic, layout structure, and event processing (and thus code). It should therefore be appreciated that the Smart client approach allows complex display-based business applications to be built from less downloaded data.

Furthermore, when different commercial applications are to be run on the device, the thin client approach of the prior art requires a completely new set of components to be downloaded. Instead, the generic client engine of the present invention, which has been downloaded and cached on the client device, can be used to generate any type of commercial application, requiring only the download of a new application subset definition file to assemble the commercial application.

Like thin clients of the prior art, such as Java applets (Java applets), the Smart client of the present invention is adapted to execute on a virtual machine that is independent of the operating system, making the more convenient port of the client available to different operating systems. However, the "Smart client" of the present invention provides the following additional benefits: it allows the use of more efficient ports for entire commercial applications for different operating systems. Unlike the prior art, where each component of each commodity application must be migrated separately, in the present invention, only the generic client engine, which may later generate any commodity application from the new operating environment, is migrated.

The Smart client of the present invention uses a well-defined internal structure of a generic client Engine to allow the generation of enhanced business applications on client devices in low bandwidth environments such as wireless networks. While network bandwidth continues to increase, the cost of running commercial applications, particularly on cellular wireless networks, continues to demand a development into strategies that minimize the amount of data downloaded.

However, in the thin client's download footprint (< ≈ 150kb), the Smart client approach provides many of the benefits of traditional dedicated fat clients or browsers (> ≈ 3-5 MB). At least two orders of magnitude smaller in size than a conventional thick client.

The application manager is adapted to operate as a separate client side layer for managing variables associated with each application segment. The application manager includes:

a control device for controlling interaction between the resident display areas;

loading means for asynchronously loading the image to the display area;

a cache device for controlling the cache;

and the analysis device is used for analyzing the application subset definition file.

The parsing means is preferably adapted to parse the compressed application definition file.

The caching tool preferably comprises means for destroying the cached image of the previous application segment in the client memory upon initiating caching of the cached image of the subsequent application segment.

The application manager may include one or more of:

a gateway stub for a short duration instantiation object;

applying memory management means between subset transitions;

a storage of hash tables, arrays, and variables; and

the online/offline cache controls the interface device of the management class.

Instead of applying interconnected code generation applets, the method applies a single generic engine that dynamically and recursively transforms itself upon receiving instructions interpreted by the parsing tool in an application subset definition file received from a server.

The one or more display managers may include one or more of the following functions:

initializing and building a device;

a component and sub-component layout device;

a data verification device;

an event processing device;

means for implementing data synchronization between display subset transitions internally within the application subsets and externally between the application subsets; and

means for storing the component/container object and associated component/container information.

The one or more load managers may include one or more of the following components:

URL parser means for asynchronously loading and parsing the remote application subset definition file by a URL parser thread;

monitor means configured to be instantiated by the URL parser means to implement timeout operations on the URL parser thread; and

an asynchronous loader device configured to instantiate at the end of the URL parser thread lifetime.

The generic client engine of the present invention may further comprise one or more publication managers configured to check the connection status with said server computer and to request transfer of client side storage data to the server computer.

The method of the present invention may be implemented in a browser-dependent manner or a browser-independent manner.

The difference between the present invention and the conventional method mainly centers around the localization of the displayed knowledge. In a traditional IDE (Integrated development Environment), the component and layout knowledge of an application is incorporated into each different applet that represents a fragment of the entire application. This applet is linked with another applet that manages the representation of the next segment of the application. Any code reuse is not done on the client side, but in the IDE. Thus, there is still a need to download all applets that differ from the previous applets in only a few ways, since it is treated as a completely different piece of information on the client side.

Instead, in the present invention, knowledge may be built into the builder engine, which contains the set of native instructions and resides on the client. The engine's native instruction set includes a generic display processor object that manages all layouts and components within the display area, and an application management layer that manages the problems associated with the entire application segment. This means that instead of loading numerous applets of the overall commercial solution, a single generic applet can be loaded which can dynamically and recursively transform itself according to instructions, by means of an application definition file based on a simple client-side application definition markup language. In a browser-related implementation, the common applet is cached on the client and remains resident for the duration of the cache deadline. Other specialized applications on the same URL may also use the same cached general applets.

The present invention provides significant additional benefits in a browser-independent implementation. Once the generic applet is installed on the client, it can be used by applications hosted on any number of URLs, since no client cache is required.

Thus, the present invention provides an instruction set presentation engine with a relatively small footprint. Due to the smart client side processing, the user interface operations are mostly handled locally. The engine maintains application user interface state information during each session, so only a small number of incremental updates are required for intermediate requests. For example, a component of a spreadsheet page may be updated without refreshing the entire page. Once all requests within the application subset are complete, the last update or other request is searched down to transform the application to the next segment of the total commercial application.

The end result is that the total commercial application constitutes the sum of the individual application subset definition files that require much less resources than downloading many application subset-specific clients. The intelligence or capabilities built into the generic client can then be used for all application subsets. Resources may be freed between transitions to different subsets of applications, which means that, while only limited client-side memory and file system storage resources are used, there is little limitation to the depth of the applications. In addition, this reduces application development time, since there is no need to encode clients for each dedicated subset of applications. Writing to the smart client without any code redundancy guarantees a minimum size compared to application subset specific clients of IDE code generation that contain code generation redundancy.

As described above, the browser-independent Smart client additionally decouples a client's relationship to a single URL. The browser-independent unsigned universal smart client is constrained by the one-to-one correspondence between client and server URLs. Thus, applications hosted on the same URL referencing the same notification applet can reuse the browser caching client, but applications distributed over multiple URLs need to load the same general-purpose client separately for each individual URL referenced. In a browser-independent implementation, this limitation is overcome because the client need not be downloaded first, allowing the federated application to be distributed over several URLs.

The invention is particularly applicable in wireless environments such as the WAP system (2.5G/3G mobile communications). In a standard server-client system, the display manager comprises a window manager. In wireless applications, a display manager manages display components and display areas on a client mobile device.

Brief Description of Drawings

The invention will now be described by way of exemplary embodiments with reference to the accompanying drawings, in which:

FIG. 1 schematically illustrates a conventional thin client development model of the prior art;

FIG. 2 schematically illustrates the Smart client development model of the present invention;

FIG. 3 schematically illustrates key structural components and relationships of the system of the present invention;

FIG. 4 schematically illustrates the initialization and loading phases of the key components of the system architecture of the present invention;

FIGS. 5A and 5B schematically illustrate the construction phase of a subset of applications;

FIG. 6 schematically illustrates an event processing phase;

FIG. 7 schematically illustrates a display transition phase search-down (kill-down) process;

FIG. 8 schematically illustrates a display transition phase overlay process;

FIG. 9 schematically illustrates caching of application target URLs; and

FIG. 10 illustrates components suitable for use in supporting the operating environment of the present invention.

Detailed Description

The following definitions are given to aid in understanding the technical field of the present invention. The following naming convention is also adopted in the present specification and drawings, namely the use of the prime notation "'" to refer to a class after the reference numeral, indicating the object of instantiation of the class.

Java and similar platforms operate using a programming environment that includes a virtual machine (e.g., JVM) so that the environment can be independent of the computer operating system and processor used to execute it.

'thin' clients are networked clients with limited local storage, and therefore storage services are typically provided on 'fat' servers. Thus, the thin client requires that all objects be transferred between the server and the client. The high-level Java code is compiled into compact, intermediate, machine-independent object code that a machine-specific interpreter translates into executable computer-specific code at runtime. In the case of applets, the applets, contained in classes and encapsulated in container files, are loaded from a server into a client, independent of the object code of the machine, and interpreted and executed in a client browser virtual machine. A browser-independent client is first installed on the client and runs within a pre-installed virtual machine on the client device.

It should be noted that while the present invention is not limited to a browser-independent engine, FIGS. 2-10 and the following detailed description are directed to an engine whose structure includes a number of features to accommodate independence from a browser.

The following description and drawings illustrate structures designed for general purpose smart client wireless applications, but those skilled in the art will appreciate that the wireless operating environment is only one area of applicability of the present invention.

Referring to FIG. 1, FIG. 1 refers to the prior art, in a traditional thin client development model, each set of main classes 10A-10N and display-specific classes 12A-12N of each application subset 14A-14N is different. Each subset 14A-14N must be separately developed, tested, and downloaded to the client device. This may result in high bandwidth requirements and/or poor performance due to the multiple different application subsets required by commercial applications 16, such as CRM and ERP systems. The more display programs 12A-12N in the application subsets 14A-14N (with associated business logic and event handling code for each display program), the larger the overall size of the dedicated client.

FIG. 2 schematically illustrates the features and advantages of the Smart client method of the present invention over the thin client model shown in FIG. 1. The total business application 16 consists of the sum of the individual application subset definition files (downloaded from application definition URLs 1-N), which requires much less computing resources than downloading multiple application subset-specific clients.

Importantly, the intelligence and capabilities required to run the applications are built into the generic client engine 20 and are then available to all of the subsets of applications 18A-18N.

Instead of creating a separate display program class 12A-12N for each display program within the application (FIG. 1), the generic client engine 20 (or builder structure) models all windows in the application 16 with a generic display manager class. A client-side markup language is used to define how the display program appears, and is incorporated into the definition files 18A-18N.

The application definition files 18A-18B are compressed for download to the client, and then the application definition files 18A-18B act to dynamically create a display program for the application 16 at the client end. As described in further detail below, the method provides the ability to (a) search down for new application instances and (b) dynamically modify current application instances with dynamic or static overrides. During the overlay, only information about data or components added or removed need be defined. The system also applies vectoring to reduce the number of image downloads required.

In addition, the number of server-side requests is reduced due to the intelligence provided to the client by the client engine 20. This is done by: (a) storing state variables of the state information at the client side; and (b) allow interaction between client-side components (without server-side intervention). The cacheable client side application java beans or applets provide a mechanism for client side interaction and service requests. In addition, this also provides a means to extend the capabilities of the engine 20 without upscaling the engine, thus allowing the user to develop highly specialized capabilities such as complex mathematical processing or visual interactions (e.g., rotating molecular structure displays).

The client-side content caching and intelligent application subset also ensures that the client device can operate along the caching path while offline. In addition, smart client-side content synchronization allows client-side applications to publish cached content to the server when resuming online operations.

As mentioned above, others have considered the challenge of developing client-side web-based applications. Unlike the present invention, these solutions typically include a Java IDE to code a commercial application as a series of applets, with a daisy chain of the applets being formed at the client end. Even if one particular applet can be categorized as a thin client, the net result of downloading many applets means that the application actually becomes a thick client.

In the present invention, the generic display processor object 22 manages all the layouts and components within the display program of the application, and the application management layer 24 (see FIG. 3) manages the problems associated with the entire application segment. The application management layer governs interaction between resident display programs, asynchronous loading of images into display programs, and cache control. It also includes a parser module to process parsing of the compressed application definition profiles 18A-18N to either convert to a new application subset (or 'client fragment') or to overlay information on an existing client fragment.

The client-side application definition files 18A-18N are based on an application definition markup language, which may be of the XML type or may use other simpler markup language forms. Following the instructions from these definition files, and due to the recursive, intelligent nature of the client, the client can then dynamically transform itself according to the path the user traverses at the client side. This alleviates the bandwidth limitation problem and provides a generic framework that is free to use whatever new features are provided in the appropriate subsequent virtual machine release version.

The architecture of the present invention enables clients to achieve a rich, open, and complex GUI look and feel in low bandwidth environments. The structural framework of the universal Smart client of the present invention is illustrated in FIGS. 3-9. These figures, in conjunction with the following description, describe the components and method steps of the present invention.

The core builder structure (or client engine) 20 is made up of seven major structural components:

an application manager 24;

a display manager 22;

a load manager 26;

a cache manager 28;

a service manager 30;

a connection monitor 32; and

a publication manager 34.

Application manager

The application management layer 24 remains resident for the entire duration of the operation of the Smart client Engine 20. Its purpose is to provide a layer through which to initialize the engine, gateway stub methods for shorter duration instantiation object communications, methods of memory management between application subset transitions, hash tables, arrays, storage of variables and objects for global scope (e.g., display manager), streaming application definition file parsers to modify the current client side application or convert it to a new application subset, interfaces for online/offline cache control management classes, and stub methods (placeholder methods) for XML parsers, cache control, connection monitors, containers, display and service management classes.

Display manager

The display manager 22 provides visual components of the application subsets 18A-18N, where one display manager object manages all components and interactions within the display program of the application. The application subset may be made up of multiple display programs representing any window type application. The application subset is defined as a set of sliding dynamically generated display programs that capture all functions of the application subset. The overall commercial application may consist of many (thousands or more) display programs, containing different components and layouts, packaging and implementing all the required commercial logic cells. The subset of applications represents a sliding view of a portion of the total application. Navigation through the entire application depends on the logical path between different subsets of applications. These paths may be dynamically generated from information stored in the current subset of client-side applications and communicated to the business logic unit hosting server, or may be static/hardwired based on predetermined paths.

The display manager 22' is an extension of the display program class 22, providing a storage unit and a method of providing the following functions:

initializing and constructing;

component and subcomponent layouts;

data verification;

event processing;

displaying data synchronization between program subset transitions internally within application subsets and externally between application subsets; and

storage of component/container objects and related component/container information.

Load manager

Load manager 26 is made up of several components:

URL Parser (URL Parser): the object asynchronously loads and parses the remote application subset definition files 18A-18N, the remote application subset definition files 18A-18N create a display manager object 22' for each new display program and instantiate, store and layout constraints specifying container/part objects and reference information in the display program. In the case of existing display programs, parts are modified or removed as instructed. The URL parser 36 also provides an application definition cache for server-side statically and dynamically generated application subset configuration URLs. If the device connection state is offline, a request to load the target URL configuration file or make a server-side service (if cached) will be retrieved from the cache. The URL parser object 36' works with the cache manager 28 to minimize network downloads and ensure application continuity in an intermittent network environment.

Monitor (WatchDog): the class 38 is instantiated by the URL parser object 36 and performs timeout processing on the URL parser thread. If the URL resolver load time exceeds a configurable timeout period, the monitor thread kills the parent URL resolver thread. If the URL resolver thread loads the remote application-defined URL before the monitor thread times out, the URL resolver thread kills the monitor thread.

Asynchronous loader (AsyncLoader): the class 40 is instantiated at the end of the URL parser thread life limit, directing each current application display manager 22' to draw and contain a 2D vector subcomponent in a 2D palette component 42.

Cache manager

The cache manager 28 is comprised of three components:

an application subset/target URL cache 44;

an image cache 46; and

a content cache 48.

Target URL cache management

The target URL cache management is handled by a URL cache manager (URLCacheManager) class 44 and instantiated by the URL resolver 36 in different ways subject to the client device connection state.

The purpose of the URL cache manager is to control the caching of target URL profiles and service requests, responses, and retrieval from the cache based on device connectivity and age of the target URL relative to the cache. In a wireless environment, the purpose of the cache manager 44 is two-fold:

loading performance in a limited bandwidth environment; and

application continuity in an intermittent network environment.

In this environment, a trade-off between subset novelty and continuity needs to be applied.

If the device is offline, the static target URL or service, plus the part name value pair, is used as a key to retrieve the previously cached target or service response. If the target URL or service response is not cached, the static or dynamic service request is ignored.

If the device is online, the remote static target URL size and date is compared to the cached version. If the remote target URL is newer than the cached version, the remote version is loaded and stored in the cache using the target URL as a data storage key. If the cache does not contain the target URL version, it is simply loaded remotely and then cached locally. In the case of a server-side service request, the service is sent to the server side and the response is cached after being parsed and processed by the URL parser 36.

Image cache management

After the image is loaded, the image cache manager 46 controls the caching of the image. It also controls the flow of images, first from the memory buffer to the client side data storage device, and finally from the data storage device when the memory is exceeded on a last in first out basis. The number of images that can be cached depends entirely on the client-side memory and storage capacity, and varies from device to device.

Content caching management

Content caching management 48 refers to the caching of collected data while the device is offline. A 'store' type service attached to a component stores all component name/value pairs in a local device data store that is part of a storage service set. The purpose of such facilities is to allow mobile devices to be used as data storage devices during offline operations. This capability used in conjunction with target URL caching means that the device may be offline and continue to execute a set of cached target URL application subsets 18A-18N, capturing and storing data as needed.

The ability to save data is useless unless supplemental publishing capabilities are provided to push that data to the server-side network via a service request while online. This may be accomplished by a direct "publish" service attached to a display component that references a set of caching services, or by an asynchronous publication manager 34 that wakes up every specified period, checks the device connectivity status, and if connected, publishes the publication service for all sets of publishing services.

Cache preloading

Both the target URL cache 44 with predefined application subsets and the image cache 46 with reference images will allow the device to function as a pre-configured offline data capture device through the pre-loading of those application subsets. It allows rapid configuration of the device for multiple uses. This is accomplished by providing an archive retrieval service that places the entire contents of the retrieval response directly into the device cache.

Service manager

The service manager 30 is instantiated in response to an event initiated by a display component attached to a server-side target service. This type controls the issuance of server requests and responses thereto. A successful response is processed by creating a URL resolver object 36' to resolve the response to the service request. The parser performs a streaming parsing of the response and, in response, creates or modifies a display program, container, component, or sub-component.

Connection monitor

The connection monitor 32 monitors the connection status of the client device to the wireless network. This is done by issuing a server-side request every specified period. If the request is timed out, the device sets the global connection status flag to false; otherwise, the flag is set to true. The connection status flags are used by both the cache management class 44 and the publication management class 34 to control cache retrieval of application subsets and content, as well as synchronization of offline storage client-side data.

Publication manager

The publication manager 34 wakes up every specified period, checks the connection status, and attempts to push/dump data stored on the client side to the server. The publication manager may also be invoked directly from a display component with an attached service tagged with a publication tag.

Turning to fig. 4, 5A, and 5B, the processing involved during initialization, loading, and building of the application subsets 18A-18N will be described.

The application manager class 24 manages all initial configuration parameter settings, the creation of globally scoped tables, dynamic arrays and parameters.

At the end of initialization, a URLparser class 36' is instantiated for loading and parsing the entry point target URL. The URLparser object 36 'creates a subset of portal applications that includes the display program with containers, components, subcomponents and all their associated information and passes it to the designated display processor object 22'.

The parseComponent () method parses all container, component or subcomponent parameters and values. When a DISPLAY or WINDOW token is encountered, the DISPLAY manager object 22' is instantiated via the parsComponent method. Subsequent components referencing the same frame are added to the display manager object 22' specific to the display program. The display manager object 22' manages the storage, layout, additional reference information, and event handlers for each container/component/subcomponent.

The URLparser object 36' is completed by instantiating an asynchronous loader class 40 to manage the progressive display of images in the reference display program 2D palette component. The asynchronous loader 40 also initializes all 2D palette components in each display program. The 2D palette initialization involves the construction of a 2D palette background image and the sizing of menus, sub-menus, and sub-menu items of a menu attached to an image button.

The 2D palette 42' is designed to provide means to allow multiple sets of visual functionality in the same visual footprint including the depth nested menus.

The monitor class 44 ensures that the target URL is loaded within a configurable upper limit. If the monitor 44' expires during the loading of the target URL, the monitor kills the URLparser thread, otherwise, the URL parser kills the monitor thread.

URLparser 36 performs streaming load and resolution of the target URL. A DISPLAY/WINDOW type component results in an instantiation of the DISPLAY manager object 22' as an extension of the DISPLAY class. All attributes of the display program (width, height, title, anchor position, background color, etc.) are passed to the display manager 22'. Subsequent parts 50, containers 52, and sub-parts are added to the display manager object 22'.

The container 52 contains a window (Form) and contained components.

The part 50 includes text fields (TextFields), text boxes (textboxes), check boxes (checkboxes), Radio Buttons (Radio Buttons), Image Items (Image Items), Buttons (button tons), pop-up Menus (pop menu), list boxes (listboxes), wire gauges (Gauge), Labels (Labels), 2D palettes (2DPalettes), and vectorization subcomponents: arcs (Arcs), Lines (Lines), Rectangles (Rectangles), ellipses (Ovals), Polygons (Polygons), Polylines (Polylines), cursor regions (Icon Areas), Image Buttons (Image Buttons), highlights (Highlight Areas), moving Image regions (Animated Image Areas), and scroll Text regions (Ticker Text Areas).

Each component/subcomponent contains the relevant parameters and configuration information in tables and vectors of the common storage class (ComponentInfo) that are stored in each display manager object 22'.

The container 52 is similar in that the configuration information is stored in tables and vectors of the ComponentInfo class.

The 2D palette components 54 may have 2D characteristics associated with them, and this information is passed to the particular display manager 2D palette referenced. Each display manager object reference is stored in an application manager table and vector for ready retrieval.

The parsing of a component is not limited to adding components, sub-components, or containers. A token to specify part/sub-part movement or modification is included in the application definition protocol to allow modification of an existing application without having to reload an entirely new application that is nearly identical to the current application.

FIG. 6 illustrates an event processing phase. Attached to many components are keyboard and mouse listeners to collect the keys that are clicked and/or the mouse press actions. If the component has a service and/or target URL attached, the process of applying the translation begins.

The component may issue a server-side HTTP POST or GET request and/or load a new target URL application definition subset file 18.

If the gotoref value is just a frame name and the service value is a servlet or cgi service name, a dynamic search down or override is performed. Firstly, calling a server-side service program, and transferring all component name value pairs of components in the same service group as initial components. If the frame name specified in the gotoref exists in the current application subset, dynamic overriding is performed, otherwise a dynamic downward search is performed to the new application subset.

Namely: service ═ servlets/myservlet motoref ═ FRAME _ HOME

If no service name is specified, but the gotoref contains the frame name and the full URL name, then a static search-down or static override is performed.

Namely: gotoref ═ FRAME _ XYZ, http:/www.abc.com/myconfig

In the case that the frame name exists in the current application subset, a static override is performed, otherwise a static search down is performed.

Other actions include: exiting the application: changing the display, clearing all display element content, saving all display element content to a local storage device, and publishing the saved data to a server.

Fig. 7 and 8 show the search down and overlay processes, respectively, in more detail.

Searching downwards: when a downward search request is issued from the current application subset, a URLparser class 36 is instantiated to load and resolve the new target URL. This is done through a stub method in the application manager 24, which application manager 24 also instantiates an asyncPluginLoader (not shown) to load the third party applet/JavaBean container URL. The details of how the downward search as opposed to the overlay is issued are given in the event processing stage, which is included in detail in fig. 6.

The new URLparser 36 "loads and parses the new target URL and dynamically builds a new application subset. Before the URLparser thread 36 goes dead, it instantiates the asyncPluginLoader class 40 to begin the process of gradually loading images into the new application subset. Asynchronous loader 40 first destroys the previous application subset display and passes control to the new application subset.

As the image is loaded into the current application subset and displayed therein, the asynchronous loader 40 and asynchronous plug-in loader threads have completed and all JavaBean and applets are loaded from their native cache libraries, placed in the current application subset, and launched therein.

Covering: in the overlay process, the URLparser 36 is also instantiated to load and resolve the new target URL, but neither the current display manager 22' or the image construction manager (imageconstmctmanager) (not shown) is destroyed. Components, containers and sub-components are added or removed from the current application subset and image construction manager to load and display new and existing images, vectorized and 2D components. Latency is minimized because the already loaded images are retrieved from an in-memory cache (not shown) or a local cache (not shown). However, the new image is remotely loaded and cached. The overlay process is also applicable to image and vectorization component removal.

The overlay facility provides a mechanism for client-server type computing over the internet, as it allows modification of the current application subset without the need to reinstall and rebuild the entire application subset.

State variable synchronization: state variable synchronization is required in the following states:

transitioning from one display to another within an application snippet;

transitioning from one spreadsheet pane to another spreadsheet pane within the spreadsheet pane component; and

transitioning from one application segment to another application segment; and

during static or dynamic overlay.

For state variable synchronization, each component optionally may have a state variable name associated with it. During any of the above transitions, the value of the component is transferred from the component to a state variable table stored in the application manager 24. After all the initial Display/Tab Pane (Display/Tab Pane) components have updated the state variable table in the application manager, the target initial Display/Tab Pane component with the state variable name attached retrieves the values from the state variable table in the application manager to set to their values.

Automatic state variable synchronization can be used to eliminate the need to handle service requests for component data synchronization during display/tab pane transitions and to minimize the amount of work required by application developers.

Fig. 9 shows how application subset target URLs are cached.

URLparser 36 checks to see if the target URL is already in the cache and not replaced by a more recent version. If it exists and is still current, it loads the application subset target URL from the local cache and parses this file. Otherwise, the target URL is remotely loaded and then cached in the local file system.

As shown in fig. 10, the digital computer 11 is connected to a pointing device 13 (e.g., a mouse or a trackball), a keyboard 15, a display unit 17, and a disk storage unit 19. The computer 1 includes a CPU and a storage unit (not shown) and is connected to a network interface 21. This enables communication with a remote server 25 via a network 23 (e.g., the internet). Such a system may be configured to perform processes embodying the present invention.

The invention then serves to allow downloading of all commercial solutions in a small bandwidth coverage area. In fact, it involves an application service engine, rather than a content service engine, and allows users to traverse multiple applications on the internet that may be functionally interconnected or completely different. For example, they may be manufacturing systems, ERP systems, CRM systems, financial systems, etc.

In one embodiment of the invention, the concept of browser-independent frames is enabled. The engine can handle all image and profile caches and the application is no longer limited to a single URL. The application may be distributed over multiple URLs that allow the creation of a relevant application 'complex'. With such a system, for example, a user may view multiple manufacturing applications hosted at multiple discrete locations and then search down for integrated financial systems hosted elsewhere.

Thus, the present invention provides a more distributed system than has been possible so far, due to the distribution of commodity logical unit representations and storage to the client-side application layer. Of course, the application can still be centrally managed.

Importantly, the system is fully compatible with existing web infrastructure. Thus, even if most of the code is actually on the server, the application appears to do as if the software is installed locally. The present invention enables user interaction in a full UGI environment and thus can be used to provide common window functionality (e.g., sorting of tables and length adjustment of columns, dynamically scaling images, and dragging and dropping items, etc.).

Tests by the applicant have shown that this ultra-thin operating environment can reduce browser-server traffic by as much as ten times.

As described above, the universal recursive client engine of the present invention allows complex display-based business applications to be built from much less downloaded data than is required by conventional thin clients. During the running of commercial applications, the download time is saved significantly. In fact, the difference between "smart clients" and "thin clients" increases as the complexity and scale of commercial applications increases.

Traditional thin client commercial solutions require thin clients that are daisy chained together. Each providing a segment of the total commercial application. The following table illustrates the difference in total application download between the two methods by a typical example of a total commercial solution (involving an initialization step and five application segments seg.1-5).

Client machine

Initial

Seg.1

Seg.2

Seg.3

Seg.4

Seg.5

Total of

Thin and slim

40kb

40kb

50kb

30kb

20kb

40kb

220kb

Intelligence

80kb (1 st time only)

5kb

10kb

2kb

5kb

8kb

110kb

In a wireless environment, the invention is suitable for use with USSD (unstructured supplementary service data) technology. USSD is a technology specific to GSM (global system for mobile communications) and built into the GSM standard, supported by WAP, for supporting the transmission of data over the signalling channels of the GSM network. USSD provides session-based communication that allows a wide variety of applications. USSD provides a desirable mechanism by which mobile devices can be used to trigger or access mobile services such as callback, interactive messaging, information query services, banking services, customer services, and mobile chat.

For example, banking applications may be enabled using the methods and systems of the present invention. The mobile user communicates with the banking server via the cellular network and the firewall system. The user connects to the URL of the banking server through his mobile device and downloads the engine and cache to the mobile device. Certificate verification and public key exchange between the banking server and the mobile device are then performed, and if successful, the system enters a secure session mode. The user then logs in with his username, account ID, password, and mobile device ID. Up to 3 failures are allowed and once login is successfully completed, the user is presented with a multi-level list of accounts and operational options. Context-specific application segments are provided to the mobile device by respective application subset definition files according to selected options (e.g., 'transfer', 'pay', 'return to option', 'exit', etc.).

Modifications and improvements to the invention will become apparent to those skilled in the art upon a consideration of the above complete description. Such modifications and improvements are intended to be included within the scope of the invention which is limited only by the claims appended hereto.

The word "comprising" and its various forms as used in this specification and claims do not limit the invention to exclude any alterations or additions.

Claims (22)

1. A method for running a display-based computer application, the application comprising a plurality of application segments, involving distributing computations between a server on a server computer and a client on a client computer, the server computer and the client computer being operatively interconnected by a computer network, the method comprising the steps of:

(a) providing a general client engine to a client computer, the client engine comprising an application manager for managing variables associated with each application segment, one or more display managers for managing displays on the client computer produced by the display-based computer application, and one or more load managers;

(b) providing a set of respective application subset definition files, each of the application subset definition files being associated with one of the application segments and each of the application subset definition files including parsable instructions for loading by a load manager onto a client computer to create one or more new display managers;

wherein upon receiving successive application subset definition files from the server, the client recursively transforms to thereby provide corresponding application segments.

2. The method of claim 1, wherein the application subset definition file defines components or layout features within one or more display regions associated with the respective segment.

3. The method of claim 2, wherein the application subset definition file defines only information about components or layout features to be added or removed between successive client updates.

4. The method of any preceding claim, wherein the application subset definition file is formatted using an application definition markup language.

5. The method of claim 1, wherein an application manager is adapted to run as a separate client-side layer for managing variables associated with each application segment, the application manager comprising:

(a) a control device for controlling interaction between the resident display areas;

(b) loading means for asynchronously loading the image to the display area;

(c) a buffer device for controlling the buffer of the image; and

(d) and the analysis device is used for analyzing the application subset definition file.

6. A method according to claim 5, wherein the parsing means is adapted to parse a compressed application subset definition file.

7. The method of claim 5, wherein the caching means comprises means for eliminating the cached image of a previous application segment from the client memory after a caching period when caching of the cached image of a subsequent application segment is initiated.

8. The method of claim 1, wherein the application manager comprises one or more of:

(a) a gateway stub for a short duration instantiation object;

(b) applying memory management means between subset transitions;

(c) a storage of hash tables, arrays, and variables; and

(d) the online/offline cache controls the interface device of the management class.

9. The method of claim 1, wherein the one or more display managers comprise one or more of the following components:

(a) initializing and building a device;

(b) a component and sub-component layout device;

(c) a data verification device;

(d) an event processing device;

(e) means for displaying data synchronization between subset transitions internally within the subset of applications and externally between the subset of applications; and

(f) means for storing information relating to the part object and/or the container object.

10. The method of claim 1, wherein the one or more load managers include one or more of the following components:

(a) URL parser means for asynchronously loading and parsing the remote application subset definition file by a URL parser thread;

(b) monitor means configured to be instantiated by the URL parser means to timeout the URL parser thread; and

(c) a loader device configured to instantiate at the end of the URL parser thread lifetime.

11. The method of claim 1, wherein the generic client engine further comprises one or more publication managers configured to periodically check connection status with the server computer and request transfer of client-side stored data to the server computer.

12. The method of claim 1, wherein the method is implemented in a browser-independent manner.

13. A distributed computing system for running a display-based computer application, the application comprising a plurality of application segments, the system comprising:

(a) a client device;

(b) a server computer operatively interconnected with the client devices by a computer network;

(c) a general purpose client engine installed on a client device, the client engine comprising an application manager for managing variables associated with each application segment, one or more display managers for managing displays produced by the display-based computer application, and one or more load managers; and

(d) a set of respective application subset definition files, each of the application subset definition files being associated with one of the application segments and each of the application subset definition files including parsable instructions for loading by a load manager onto a client device to create one or more new display managers;

wherein the client device is configured to recursively transform upon receiving successive application subset definition files from the server computer to thereby provide respective application segments.

14. The system of claim 13, wherein the application subset definition file defines components or layout features within one or more display regions associated with the respective segment.

15. The system of claim 14, wherein the application subset definition file defines only information about components or layout features to be added or removed between successive client updates.

16. The system of any of claims 13 to 15, wherein the application manager is adapted to run as a separate client-side layer to manage variables associated with each application segment, the application manager comprising:

(a) a control device for controlling interaction between the resident display areas;

(b) loading means for asynchronously loading the image to the display area;

(c) a buffer device for controlling the buffer of the image; and

(d) and the analysis device is used for analyzing the application subset definition file.

17. The system according to claim 16, wherein the parsing means is adapted to parse a compressed application subset definition file.

18. The system of claim 16, wherein the means for caching comprises means for eliminating cached images of a previous application segment from the client memory when caching of cached images of a subsequent application segment is initiated.

19. The system of claim 13, wherein the application manager comprises one or more of:

(a) a gateway stub for a short duration instantiation object;

(b) applying memory management means between subset transitions;

(c) a storage of hash tables, arrays, and variables; and

(d) the online/offline cache controls the interface device of the management class.

20. The system of claim 13, wherein the one or more display managers include one or more of the following components:

(a) initializing and building a device;

(b) a component and sub-component layout device;

(c) a data verification device;

(d) an event processing device;

(e) means for displaying data synchronization between subset transitions internally within the subset of applications and externally between the subset of applications; and

(f) means for storing information relating to the part object and/or the container object.

21. The system of claim 13, wherein the one or more load managers include one or more of the following components:

(a) URL parser means for asynchronously loading and parsing the remote application subset definition file by a URL parser thread;

(b) monitor means configured to be instantiated by the URL parser means to timeout the URL parser thread; and

(c) a loader device configured to instantiate at the end of the URL parser thread lifetime.

22. The system of claim 13, wherein the generic client engine further comprises one or more publication managers configured to periodically check connection status with the server computer and request transfer of client-side stored data to the server computer.