The present invention relates to the specification and generation of applications in a client-server environment, and in particular, Web applications. Technical Field

The term Web application means an application accessible over the Web using a network, such as an intranet or the Internet, and using as a client-side terminal a normal Web browser. Background Art

This application model became popular towards the end of the 1990's as an alternative to the traditional client-server model compared to which it offers a number of advantages: easier distribution and updates, since a Web application resides entirely on the server and so, by updating the version on the server, the new application is immediately available to all of the clients; multi-platform access, meaning the same application is available to users independently of their hardware and operating system; a reduction in operating costs, since the use of Internet infrastructure significantly reduces both connection costs and the cost of managing clients; increased scalability, since a Web application can grow reasonably easily in-line with a company's requirements.

The classical Web application model functions in the following manner: user operations in the Web interface generate HTTP requests which are forwarded to the Web server. The server responds to the request by accessing stored data, performing numerical manipulation, optionally accessing various databases or proprietary systems, and finally returning an HTML page to the client.

This model has been used since the first days of the Web, which was initially envisioned not as an application platform, but as a way of disseminating documents in a distributed environment; for this reason the model is not ideal for the creation and distribution of application software, in particular since it does not allow the creation of advanced user interfaces given the absence of the concept of application state, the limited number of native interface components and the inconsistencies between the various browsers. Furthermore, every interaction with the user interface involves a delay whilst the server services a new page request which must then be sent to and rendered by the browser, which means the responsiveness of the application depends on the responsiveness of the Web server. For all these reasons, it is difficult to create Web applications which have the same usability and responsiveness typical of traditional desktop applications.

To obviate these drawbacks, in recent years a new generation of Web applications have been devised which permit a totally new type of interaction, based on the best functional and engineering aspects from both the Web application and desktop worlds: these kinds of applications are called Rich Internet Applications (RIA).

RIAs have similar characteristics and functionality to traditional desktop applications, without however requiring installation on the local file system.

RIAs are notable for the level of interactivity and their speed of execution. Part of the computational burden is transferred to the client, which results in a much more responsive user interface, whereas the majority of both the user data and the application proper remain on the remote server, with a consequential beneficial impact on the performance of the client computer.

Over the last few years the success of the RIA paradigm has led to the creation of numerous technological platforms and development tools for the creation of RIAs.

One route RIA development has taken has been to overcome the intrinsic limits of the browser through the use of software extensions, known as plugins, which can be downloaded and installed from the Web. They allow the visualization from within the browser of highly-interactive multimedia applications. Macromedia Flash is an early example of this type of plugin, whereas a key development has been to make the plugins programmable: Adobe Flex and Mircosoft Silverlight, for example, allow applications to be programmed via a combination of declarative languages for the user interface (MXML in the case of Flex, and XAML in the case of Silverlight) and a scripting language (Actionscript and Javascript, respectively)for the definition of interaction logic with the user.

This approach brings a number of advantages: it allows very rich applications to be created which employ animations, vector graphics, video and audio playback, and which together yield an articulated and immersive user experience. However, these advantages come at a price: users need to download the plugin, leading to potential barriers to adoption; and developers are faced with a steeper learning curve.

As an alternative to plugins, in the last few years technological platforms have been devised which allow RIAs to be created using native browser functionality and traditional programming practices. In particular, platforms based on Ajax technology (Asynchronous Javascript and XML).

Aj ax does not refer to a particular technology, rather a set of related Web technologies. Ajax is based on the exchange of information in the background between the web browser and server, and allows a web page to be dynamically updated without issuing an explicit page reload request. Ajax is asynchronous in the sense that the information is requested from the server and loaded in the background without interfering with the page that made the request. Ajax utilizes a combination of HTML (or XHTML) and CSS for markup and styling respectively, DOM (Document Object Model) which is manipulated with an ECMAScript language such as Javascript or Jscript so as to display and integrate fetched information, and finally the XMLHttpRequest object for the asynchronous exchange of information between the user browser and web server. Generally, XML is used as the format for exchanged information, although any underlying format can actually be used. These files are generally created dynamically by server side scripts.

In many cases the pages comprising a Web application contain many common parts; with traditional methods these common parts are re-sent with every page request. Instead, with Aj ax, a Web application can request only those parts that need updating, with a consequent drastic reduction on bandwidth usage and responsiveness.

By utilizing asynchronous requests, which allow portions of the page to be updated individually, the user interface becomes more interactive and responsive, given that the quantity of information exchanged between the client and server is reduced. Furthermore, the use of Aj ax can also bring about a reduction in server connections, since scripts and style sheets need be requested only once. Server responsiveness also decreases because a large part of the data elaboration occurs on the client.

Numerous frameworks exist to aid the creation of Ajax-based Web applications: in general they provide collections of utilities and controls which render the creation of interfaces easier by allowing the graphical aspects of the application to be improved without writing additional code.

In general, Ajax frameworks introduce a layer of intermediate code between the client and server, which is frequently denominated a client engine. The client engine is generally downloaded when a Web application is first initialized and further components can be downloaded as required as the application executes. The client engine basically extends browser functionality and generally manages the user interface and communication with the server.

Dojo Toolkit and Sproutcore represent some of the most complete Ajax frameworks available: both allow sophisticated user interfaces to be created by making standardized functionality available which is similar to that available in desktop applications, such as simple cut and paste, undo/redo, keyboard shortcuts, menus and tree-based controls. Furthermore, they provide a rich internal data management model, and tools for the preparation and optimization of code prior to release; for example Dojo allows for the generation of packages: a Javascript file containing all those javascript functions, with resolved dependencies, required by an application. Sproutcore generates a limited number of static files which correspond to all the dynamic files specified during development, thus reducing the quantity of Javascript deployed to the client.

The development of platforms and technology for the creation of RIAs is a very active area, is in continual evolution, and is still not mature. There is a burgeoning requirement to create more sophisticated Aj ax frameworks, which provide for multi-functional applications to be developed, better client-side performance, significant compression of information exchanged between client and server, increased ease of use, increased flexibility in the creation of interfaces and functionality, and above all a more intelligent management of the flow of data and components from the server to the client. Disclosure of the Invention

The primary aim of the present invention is to provide a system and method for the specification and generation of Web applications which provides better performance and more sophisticated functionality with respect to the pior art.

Within this aim, the present invention relates to a new system whose objectives are to be of simple application and construction, and of lending itself to easy integration with existing software and hardware devices.

This aim, these and other objects which will become better apparent from the description of the present invention, are achieved by a method for the running of applications in a client-server environment comprising the steps of defining, starting from a set of components, a plurality of arrangements of said components, which constitute an application; defining a navigation map on the basis of said arrangements or said components; transmitting from the server to the client the components required for an arrangement to be displayed in a client-side program in a current display step; determining, for each arrangement, the set of components that can be reached in subsequent navigation steps; tracking the components transmitted from the server to the client during navigation; sending, during said current navigation step, said components that can be reached in said subsequent navigation steps.

Conveniently, subsequent navigation steps are those navigation steps which are immediately successive to the current navigation step.

Preferably, the method also comprises a step in which the client transmits to the server information regarding components which had been previously transmitted, and then subsequently eliminated, on the client; and also a step in which the client transmits to the server information regarding components which have been displayed during the current navigation step.

This aim and objects are also achieved by a system for the running of applications in a client-server environment comprising the steps of defining, starting from a set of components, a plurality of arrangements of said components, which constitute an application; defining a navigation map on the basis of said arrangements or said components; transmitting from the server to the client the components required for an arrangement to be displayed in a client-side program in a current display step; determining, for each arrangement, the set of components that can be reached in subsequent navigation steps; tracking the components transmitted from the server to the client during navigation; sending, during said current navigation step, said components that can be reached in said subsequent navigation steps. Brief description of the drawings

Further characteristics and advantages of the invention will become apparent from the description of a preferred but not exclusive embodiment of the system and method for the storage of documents, shown for illustrative and not limiting purposes in the attached drawings, wherein:

Figure 1 is a block diagram describing the architecture of the system according to the present invention.

Figure 2 shows an aspect of a definition of an application according to the present invention.

Figure 2a shows an example of how a screen may be displayed to the user according to the present invention.

Figure 2b shows an example of how another type of component, a FAB block, may be specified and displayed to the user in two different ways, according to the present invention.

Figure 2c shows a possible embodiment of a repository for storing and managing components, according to the present invention.

Figure 3 shows a tree-based representation of a navigation map for a web application, according to the present invention.

Figure 4 is a flow diagram for a form of embodiment of the "compilation" method, ie the preparation of an application for deployment, and in particular the transformation of an application specification into a component database, according to the present invention.

Figure 5 is a flow diagram for a detailed form of embodiment for the step of creating a navigation map, according to the present invention.

Figure 6 is a flow diagram for a detailed form of embodiment for the step of factoring screens, according to the present invention.

Figure 7 is a flow diagram illustrating the communication steps between client and server during an application execution. Ways of carrying out the Invention

An example architecture of the system according to the present invention is summarized in figure 1.

Figure 1 shows a client-server architecture, comprising of a server 10 and a user agent 20. The server is a component which accepts requests from clients, ie user agents, and sends data and other information in reply. The server can run on a dedicated machine, or be run on a machine which also runs software dedicated to other tasks. In a preferred embodiment, the server 10 can be implemented in conjunction with common Web servers such as Microsoft Internet Information Server or Apache HTTP Server. The user agent is a component which is able to interpret and visualize the information received from a server, thus permitting users to interact with this information. User agents may be installed on common personal computers, but also on other devices such as hand held devices and smart phones. In a preferred embodiment, the user agent 20 can be implemented by known web browsers such as Microsoft Internet Explorer or Mozilla Firefox. In a preferred embodiment, the communication between the web server and browser occurs over HTTP, and the various web servers and browsers are interconnected by a network such as the World Wide Web, but also an intranet, or any network which supports asynchronous communication between client and server. As will be described in more detail in the foregoing, the server and the user agent, according to the present invention, communicate via requests for components and the supply of components.

According to the present invention, the server comprises a manager for communication with the client 11, a component database 12, a database for holding client states 13, and a repository for the storage of user data 14. The manager for the communication with the client 11 is the fulcrum of the server side implementation, and is responsible for servicing client requests. The component database 12 contains all of the building blocks necessary for generating the client side application and, as described in the foregoing, is populated during the compilation phase. The component database also contains other data structures necessary for describing the relationships between the various components in the component database, such as the navigation map, as shown in figure 3. The database for holding client states 13, comprises for each active user a representation of the current navigation state, which entails both the currently selected screen and the currently selected menu option. Finally, the repository for the storage of user data 14 contains data structures which hold user information which may be required during a user session.

Operation of the system is as follows: upon receiving a client request, the manager for communication with the client 11 calculates the current state of the client application in conjunction with the database for holding client states 13, it may interact with and modify the contents of the repository for the storage of user data 14, and, in cooperation with the component database 12, creates a file, known as a package, which contains all those components required for navigation states which can be directly reached from the current navigation state, and which have not already been sent to the client, or which have been previously sent to, and thereafter eliminated by, the client, as described in more detail in the foregoing. The generated package is then sent in reply to the request from the user agent 20. This method of operation, known as preemption, forms the basis of the system behavior, according to the present invention.

The user agent, according to present invention, comprises a manager for communication with the server 21 and an interface between the user and the user agent 22 which in turn contains a user interface 23 and a system for manipulating the user interface 24. During user navigation within an application, each time the user selects a menu option, the manager for communication with the server 21 sends to the server 10 a message regarding the selected menu option, which the manager for communication with the client 11 utilizes to update the current navigation state and to compute the components which need to be sent to the client, as previously described. The interface between the user and the user agent 22 is responsible for displaying the correct screen each time a menu option is selected, which is achieved by using the system for manipulating the user interface 23 to make any necessary changes to the user interface 24. In a preferred embodiment, the user interface 23 corresponds to a Web document tree (DOM, Document Object Model) and the system for manipulating the user interface 24 corresponds to a scripting environment, utilizing a common scripting language eg Javascript. It should be noted that, on the basis of the principle of preemption, the interface between the user and user agent 22 does not have to wait for a response from the server 10 before displaying the current screen because all the necessary components will have been previously downloaded to the client.

Figure 2 shows an aspect of a definition of an application according to the present invention. The figure shows two examples of screens: the screen is the main element of an application specification according to the present invention. The screen contains a plurality of panels, or panes; each pane can itself recursively contain another screen, so as to allow a system of nested screens. As described in more detail later in the foregoing, the screen represents a key element used to define an application navigation map; furthermore a screen represents a key contextual element, to the extent that all other components and data structures are defined in terms of the screen in which they occur.

From a graphical perspective, in a preferred embodiment the screen is divided into five panes: a central pane, known as a canvas, surrounded by panels above, below, to the left and to the right. The figure illustrates two possible arrangements of panes within a screen. Apart from the central pane, all the other panes are optional.

According to the present invention, applications are defined in terms of components: components are conceptual abstractions which permit the specification, organization and management of an application in a more intuitive manner than can be achieved through the sole use of the constructive blocks of a traditional application, such as, in the case of a Web application, HTML, Javascript, CSS and data structures. For reasons of efficiency, a wide variety of component types may be supplied by the server 10, but once on the client each is converted into a fundamental underlying primitive. In a preferred embodiment, components are specified using a declarative syntax. Prior to application deployment, this specification is "compiled" into a plurality of data structures, the component database 12 (as shown in the preceding figure) which represents a key reference point in the communication between the client and the server.

According to the present invention, an application is specified in terms of a hierarchical series of specification records; the initial specification record is termed the project record; each specification record can reference another one.

The project record contains the definition of the initial application screen. For illustrative and not limiting purposes, a possible initial screen definition is shown in Table 1.

screen =

[ SCR_ID = Root: declare = { ScreenA, ScreenB } : paneTH r menu = [ name = Menul : type = msh

]

] paneCV , r m link = Menul ] : add menu = [ id Menul : items = [ text ^A Option 1 ^Λ : screen = ScreenD ]

[ text ^A Option 2 ^A : screen = ScreenE ]

[ text ^A Option 3 ^A : screen = ScreenF ]

]

]

]

Table 1

The specification declares two child screens, screen A and screen B. These screens are declared rather than included which means an instance of them is not incorporated into the parent screen definition, but both are still considered child screens. This guarantees, as described in more detail later in the foregoing, that child screens, and all the components these reference, will be present on the client when the parent screen is required, The specification continues by defining two panes, a top horizontal pane, which contains a menu display, Menul, and the central pane, whose contents will be the screen referenced by the currently selected menu option. Lastly, the menu, Menul, is defined as having three options. For each the appropriate menu text is specified, as well as the correct screen to be displayed should the menu option be selected by the user. In a preferred embodiment, when the example screen is displayed by the user agent 20, the dynamic content is inserted into the canvas pane and the system calculates the height and width of any relevant external panes so as to apply the exact dimensions to the canvas pane so that it adapts perfectly to the space available to it. If, at a later stage, the size of the browser window is changed, the external panes maintain some of their dimensions, and the canvas is resized to the correct size. The above example definition of an initial screen could be displayed by a user agent 20 as shown in figure 2a.

Apart from screens, other fundamental components according to the present invention are templates', a template is a portion of code, for example HTML, which contains a series of attributes which, during the creation of template instance within an application, are substituted with other code, or values, on the basis of a series of substitution rules which depend on the context in which the template is being utilized. In a preferred embodiment, the substitution syntax consents a vast array of operations which are used in conjunction with the boolean algebra which can be expressed by the syntax. A particular feature of the present invention is that template instantiation occurs on the client rather than the server, and is managed by the interface between the user and the user agent 22. For illustrative purposes, Table 2 contains an example template used to display items from a tree structure.

Table 2

The template defines an HTML DIV element containing a SPAN element. The text and the class of the SPAN element vary according to whether the item to display is a node or a leaf.

Another fundamental component is the menu: a menu is an object comprising a series of options, and the user selection of an option entails a corresponding screen being displayed. According to the present invention, menus are therefore fundamental to user navigation within an application and for the identification of state transitions, as outlined in more detail later in the foregoing.

Other useful components for the definition of an application interface are FAB elements (Floating Menus and Buttons). These elements are specified in terms of groups, blocks and items: each group is composed of blocks, and each block references an item, and each item may contain a reference to a screen. In conjunction with templates, FAB elements can be displayed in a variety of different styles. Figure 2b shows an example of a FAB specification along with two possible visualizations.

Table 3 shows a possible embodiment of an extension to the sample definition presented in Table 1 in which a lower pane is used to display two buttons.

screen =

[ SCR_ID Root : fab_def = [ g = [ lgGroupl = { lbBlockl} ] : b = [ lbBlockl = { lilteml, Iiltem2 }] : i = [ lilteml = { giltem,

[t = ^A Screen One ^A : s = ScreenA ]

Iiltem2 = { giltem,

[t = ^Λ Screen Two ^A : s = ScreenB ]

}

J

] paneTH [ menu = [name = Menul :type = msh ] ] : paneCV " = [ m link = Menul ] : paneBH = [ flow = [id = lgGroupl ] ] : add menu = [ id = Menul : items = [text = ^Λ Option 1 ^A : screen = ScreenD ]

[text = ^A Option 2 ^A : screen = ScreenE ]

[text = ^A Option 3 ^A : screen ScreenF ]

]

]

Table 3

A further useful component for the creation of applications according to the present invention are datasets: the datasets are data structures which are used for the management and manipulation of both user data and system components. A dataset contains a number of attributes. One defines the dataset type, another contains a flat structure containing the records, and finally a third contains a structure which maps the relationship between the records. A record can contain actual values, or alternatively a reference to another dataset. This allows a dataset to function as a view (similar to an SQL view) on another, normally much larger, dataset and means only a subset of records, those referenced in the view, need to be downloaded to the client. When the structure or content of a view are modified on the client, the system of references allows the data underlying the view to be updated automatically on the server. In a preferred embodiment, all of the datasets used by an application are stored in the same SQL table; this aids rapid prototyping since the developer can avoid planning a specific SQL table structure in the development phase. Prior to deployment, any dataset can be implemented in its own personalized table, which may be appropriate for performance reasons.

As mentioned previously, all the above components, apart from datasets containing user data, are stored in specification records which are themselves stored in a specification repository. Figure 2c shows a possible embodiment of a specification repository according to the present invention. The specification repository can be implemented using a file system or a relational database. At the top of the drawing are listed the identifiers of the libraries, LIB, LOC, PROJ_A. Each library is organized in terms of categories, which are used to store similar items, eg templates, screens, or scripts. Libraries share a common structure, and function on a cascade principle. When the compiler encounters a reference to a library item, it first searches LIB, then LOC and finally PROJ_A. It will use the last reference it finds. For example, if LIB contains a certain screen template, the developer could simply create an alternative template with the same name and place it in PROJ_A; this now means that all parts of the PROJ_A application will use the new template definition, without requiring any path names to be changed in the various components which referenced the original template.

Figure 3 shows a navigation map for an application according to the present invention. The navigation map is generated automatically from the application specification, and is represented as a tree structure whose root is the initial screen, and whose nodes are composed of screens and menus. The parent-child relationship between the elements in the tree are inferred by the fact that a screen can include other screens or menus, and that menu options reference a screen. For example, in figure 3, the initial screen references screen A, screen B and Menul, hence the navigation map tree has as its root the initial screen, which has the following children: screen A, screen B, and Menul. Proceeding in the same manner for these screens and menus, and for those subsequently encountered, the entire navigation map can be generated. The navigation map is a key structure in determining which components need to be sent in reply to a client request within the context of preemptive operation, as explained in more detail later in the foregoing.

Figure 4 shows a possible embodiment of the compilation method according to the present invention.

In step 410 the compiler (not shown) generates, starting from an application specification in terms of screens, menus and components, a navigation map between screens and menus, ie the tree structure shown in figure 3. The navigation map is stored in the component database 12. In step 420 the compiler augments the navigation map by adding as children of each screen all of the components contained in the same screen. It also recursively adds any components required by said components, thus generating the application structure map. In this phase the compiler also generates a list which maps for each screen all those components referenced either directly or indirectly; and another list which maps for each component the screens in which the component appears. The structure map and the two lists are stored in the component database 12. In step 430 the compiler proceeds to factor the screens utilized by the application. This entails identifying those screen definitions (i.e. specification records) which are referenced more than once within the application specification and creating for each a generic version of the screen, from which are isolated those parameters required to recreate each specific screen instance. In step 440 the compiler applies some consistency checks which, for example, entail ascertaining that all referenced components are present in the system, or making sure any script calls are to valid and present Javascript functions, or that any references to CSS style sheets are valid. If any consistency checks fail, the compilation halts and an appropriate error message is generated, as per step 480. Otherwise, as per step 460, the compiler generates the application state map, ie a finite state map in which the current state is represented by the current screen and currently selected menu option, and the state transitions are represented by those screens reachable by selecting a menu option in the currently displayed screen. Finally in step 470, the compiler generates a number of other data structures and files necessary for the initial state (which is the same for all users). In particular, this step involves grouping those components necessary for displaying the initial screen, and those screens reachable in one navigation step from the initial screen. In a preferred embodiment, these components are stored in two XML files, the first, the boot package, contains those components required for the initial state, and the second, the boot_pre package, contains those components needed for screens reachable from the initial screen in one navigation step. Further, a launch file for the application is generated, preferably an HTML file similar for all applications containing a script which informs the server 10 of the application launch, requests the boot and bootjpre packages, and displays the initial screen.

After these steps have been successfully completed, the compilation terminates and the application is- ready to be deployed. The compilation can occur directly on the server 20, or alternatively on a dedicated development machine (computer). In this case, prior to deployment it is necessary to transfer to the server 20 all the files generated during the compilation phase, and in particular the component database 12.

Figure 5 shows in greater detail step 410 in which the navigation map, according to the present invention, is generated. In step 510 the method begins with the initial application screen, which it assigns as the current node, and creates a tree structure to whose root is assigned the identifier of said initial screen. In step 520 the method analyzes recursively, if appropriate, the specification of the current node so as to identify any declared or included screens (in the case the current node is a screen) or alternatively to identify any referenced screens (in the case the current node is a menu). If at least one such screen or menu is identified, in step 530 the method augments the previously created tree structure by adding to the current node a child for each element. In step 540 the method ascertains whether there are any child nodes of the current node which have not yet been analyzed. If such a node is identified, step 550 makes this node the current node and control passes to step 520, where the analysis continues in a recursive manner on the current node and its children. Alternatively, if step 540 ascertains that it has analyzed all the child nodes of the current node, control passes to step 560, in which the method checks whether the current node is the root node in which case the generation of the navigation map is complete, and, as per step 580, the method terminates. If the current node is not the root node, the method assigns as the current node the parent of the current node and passes control to step 540, in which the analysis of the structure proceeds. If, in step 520, the method ascertains that the initial screen does not contain any screens or menus, the method proceeds with step 560 and terminates; in this case the navigation map is empty.

At the conclusion of this method the system has generated a navigation map for the application similar to that shown in figure 3.

Figure 6 is a flow diagram which illustrates in greater detail a form of embodiment of the step which is responsible for screen factoring according to the present invention. The method cycles through the list of screens, one of the structures generated by the compiler in a previous step. In step 610 the compiler assigns as the current screen the first screen in this list. In step 620 the compiler checks whether the current screen is used more than once within the application, i.e. if more than one screen within the application is based on the same screen definition. If this is not the case, control passes to step 650. If it is the case, the compiler creates a generic screen definition by copying the original screen definition containing the screen definition without any of the modifications contained in the specific screen instance, and placing it in list of clone screens. Thereafter, in step 640 the compiler creates a list of modifications which must be made to the generic screen so as to be able to recreate each of the said specific instances of the generic screen. In step 650 the compiler checks whether the last checked screen was the last in the list: if this is the case, with step 670 the method terminates, otherwise control passes to step 660 in which the compiler assigns as the current screen the next screen in the list and passes control to step 620.

Figure 7 is a flow diagram illustrating the communication steps between the user agent 20 and the server 10 during an application execution.

At application launch the user agent 20 requests from the server 10 the launch file for the application. In a preferred embodiment the launch file would be an HTML file which would be of a common format for all applications, comprising a simple structure containing a BODY tag which contains an attribute which identifies the application, and a link to a Javascript launch script which sends a message to the server 10 informing of the application launch. At this point, in step 710, the server 10, and in particular the manager for the communication with the client 11, creates a state structure for the current session by cloning the initial state structure generated during the compilation phase. Simultaneously, the user agent 20, and in particular the manager for communication with the server 21, checks (if it has local caching ability) whether the two boot packages are available in the cache, and if not, it requests them from the server. Thereafter, the user agent 20 installs the boot package in step 740. At this point, all the components necessary for displaying the initial screen are present, and so the user agent 20 passes to step 750 in which the initial screen is displayed. Simultaneously, in step 760, the user agent 20 loads the boot_pre package which contains the components which are required by those screens which can be reached from the initial screen in one navigation step. The boot_pre package is not 'expanded' in this phase, i.e. no component instances are created from the contents of the package. At the end of this phase, the user agent 20 is ready to accept user input.

Each time the user selects a menu option, such as for example in step 780, the user agent 20 sends to the server a message communicating the change in the client's navigation state, and including details of the newly- selected menu option. The user agent 20 sends said state change message in an asynchronous manner. This means that once the message is sent, in step 785 the user agent displays the screen referenced by the menu option without waiting for the server 10 to respond. This is possible because, on the basis of the principle of preemption (previously described), all the components required for the display of the new screen will already be present on the client. The server 10 utilizes the information contained in the state change message to update the current state of the application, as per step 790, and, based on the state map and the navigation map, in step 795 generates a list of all components needed by those screens which are reachable from the current screen in one navigation step, and that have not already been sent to the client, or have been previously sent and thereafter deleted on the client. In step 800, these components are organized in the form of a package, preferably an XML file, and sent to the client. Thereafter, the list of components present on the client (for this particular session) is updated to include those components present in the package. In step 805, the user agent 20 waits until the screen relative to the new navigation state has been displayed before processing the response from the server 10. If the response contains a package, the components contained in the package are extracted and stored locally.

Generally, every time a new screen is displayed, regardless of how it is selected: via a menu, a button, or other means, the user agent 20 automatically sends a state change message to the server 10, whose response will contain a package if necessary.

In the event of a user selection not provoking a new screen to be displayed, for example following the pressing of a button, as in the case of step 810, this action does modify the application state of the client but the user agent 20 may nonetheless optionally send to the server 10 a similarly asynchronous notification message which can be used by the server 10 to track component usage or user navigation in greater detail.

Finally, the user agent 20 sends a message to the server 10 in those cases when, for memory usage purposes, a component is deleted from the client, such as in step 820. The server 10 uses this information to remove the deleted component from the list of already sent components for that specific session.

The above described embodiments may be implemented in many different ways and the present invention is not limited to any particular implementation.

Furthermore, notwithstanding the various methods described have been conveniently implemented within a generic computer appropriately activated and configured by means of executable software, an expert in the art would be able to recognize that such methods could also be implemented in hardware, firmware or devices specifically constructed to carry out the steps required by the method.

It has been demonstrated that the present invention achieves the aims and objects as stated. In particular, it has been shown how the system and methods hereby described, exceed the qualitative limits of the prior art, given that, on the basis of the preemptive sending of components, they are able to increase the performance of the client. Server latency following user interface interaction has been eliminated since all components necessary to service the interface request have already been downloaded to the client. Furthermore, screen factoring and the use of client-side templates provide for a significant compression of the information transferred from the server to the client, with a consequent positive impact on bandwidth utilization, which is particularly relevant to devices using slower (e.g. mobile) networks. A highly modular approach, as embodied by the use of components, aids both the development and the provision of highly complex applications; it permits a high level of component reuse and allows for the highly-granular tracking of component usage and user navigation, with each creating new opportunities for billing models. Finally, the compile-time consistency checks promote the creation of robust applications, in which the possibility of referring to inexistent components has been eliminated — thus obviating the need for a large portion of standard client-side tests.

It has been further demonstrated how the present invention is of practical realization, since the steps of the methods used consist of simple manipulation operations on data structures which use syntaxes and techniques of a form known to the art.

Clearly, numerous modifications may be applied by an expert in the art without exceeding the scope of protection of the present invention.

For example, it is possible to envisage an integrated design environment (IDE) for the generation of web applications which employ the present invention, incorporating, optionally, a graphical interface for the specification of applications. This would further increase the simplicity of the present invention, by allowing for the creation of user interfaces without the necessity of writing HTML code or utilizing specialized specification syntaxes.

It also clearly appears that the innovative concepts underlying the present invention are not dependent on the specific choice of module language or languages, and are similarly independent of the choice of hardware platform; to the extent that the present invention may be also be incorporated directly into the firmware of modern electronic devices. Therefore, the extent of the protection afforded to the present claims should not be limited to the illustrations or preferred embodiments, included here merely for explanatory purposes, rather the extent of the present claims should encompass all the patentable aspects of the present invention, including all those characteristics which would be viewed as equivalents by an expert in the art.

The disclosures in Italian Patent Application No. MI2009A000252 from which this application claims priority are incorporated herein by reference.

Where technical features mentioned in any claim are followed by reference signs, those reference signs have been included for the sole purpose of increasing the intelligibility of the claims and accordingly, such reference signs do not have any limiting effect on the interpretation of each element identified by way of example by such reference signs.