Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/90—Details of database functions independent of the retrieved data types
  • G06F16/95—Retrieval from the web
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F9/00—Arrangements for program control, e.g. control units
  • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
  • G06F9/44—Arrangements for executing specific programs
  • G06F9/448—Execution paradigms, e.g. implementations of programming paradigms

Definitions

• the present invention relates to the architecture and deployment of custom web applications.
• a Web application is typically in the form of HTML (HyperText Markup Language) or XHTML (HTML 4 to XML), from a Web server and running in a browser (English browser). ) on the user terminal of the user.
• HTML HyperText Markup Language
• XHTML HTML 4 to XML
• the user is then able to interact with the application by going from one page to another by clicking on hypertext links or by filling in forms.
• These actions correspond to a request sent to the web server via the browser according to the protocol of the Web, namely HTTP (acronym for HyperText Transport Protocol).
• HTTP HTTP (acronym for HyperText Transport Protocol).
• the server decodes and executes the request, then returns, again via the HTTP protocol, a new HTML page that corresponds to the result of the execution of the request. This page is then displayed by the browser and the user can view it and continue to interact with the application from this new page.
• the architecture allowing the deployment of such applications is therefore adapted to the request-response model and the HTML presentation format, that is to say that an application from a web server decodes queries, performs processing to compute the response data, format these responses in HTML format, and return the final page to the requestor, the web browser installed at the user's endpoint.
• a Web application thus consists in the installation of its program on a Web server, which will manage the exchange of messages in HTTP format, and often in the interconnection of this application with databases in which the application will be able to draw the data to present.
• Customizing a Web application is to make this application the best suited to the needs and characteristics of each user, for example by providing quick access to the functions that it performs most often, allowing it to automate certain suites of treatment, presenting him with a human-machine interface (HMI) that corresponds to his preferences, etc.
• HMI human-machine interface
• the known solutions for customizing web applications are the following (not mutually exclusive, they can add up): integration of a customization program in the program of the application itself.
• This generic customization program is then scheduled to be executed by the program of the application on the Web server during each processing (decoding and execution) HTTP request received from a user via his browser.
• the effect of such a personalization program on the processing of the request is then to potentially come to modify the nature or adapt the formatting of the results of the execution of the query; use of personalization programs diversified by the program of the application (according to the users or, more generally, the user profiles).
• These diversified customization programs are then selected to be executed with the application (as described in the previous point) according to the user (or his profile) who issued the request;
• HTML pages corresponding best to the uses and preferences of the user. For example, if a Web application offers a dozen features (for example, via a list of hypertext links) and the user usually uses only three, the application customization program can consist of ordering access to these ten features most at least used by the user. This can be achieved by registering in the "Users" database a feature-based counter, which is incremented each time the user uses a feature.
• the customization program which is integrated into the application program on the application's web server, consults the list of counters, sorts it, and integrates it in an orderly way into the results page that is returned by the Web application to the application. user terminal browser. This personalization program must also maintain this list of counters, that is to say, increment the counter corresponding to the functionality that has just been requested by the user.
• the web server intended to execute, on request, the program of the application must also run the personalization program to achieve the final custom final page required before serving it to the client terminal.
• program management and personalization data have the same general characteristics, particularly in terms of availability, scalability, adaptability and security, as those related to the management of the application itself. .
• the architecture of a custom web application as it stands today is essentially monolithic and offers few facilities and guarantees that customization is available anywhere for the user, or that it can be evolve (to enrich or simplify) regardless of the application, or the fact that it can adapt to the content of the application and the environment in which the application runs (for example a station workstation or mobile phone), or the fact that the user's private data needed for personalization is protected.
• the present invention aims to solve one or more of these disadvantages, by proposing the implementation of custom web applications mainly ensuring the decoupling of programs and personalization data with respect to the application parts from the Web server.
• the subject of the invention is a method of customizing a Web application, intended to be executed on a terminal of a user via a browser equipping the terminal, on request sent via a telecommunications network from the browser to a remote web server hosting the application, characterized in that it comprises: -hosting at least one personalization program and / or personalization data by a local server specific to the user associated with the terminal and
• the local server specific to the user is made in the form of a web server embedded in a portable digital device connected to the terminal of the user.
• the local server specific to the user is installed on the terminal of the user.
• the step of mixing the data relating to the Web application with the personalization program and / or the personalization data is performed in the browser of the terminal of the user through which executes. the application.
• the mixing step comprises:
• the step of mixing the data relating to the Web application with the personalization program and the personalization data is performed in the remote server.
• the mixing step comprises:
• access to the program (s) and / or personalization data on the local server is secure.
• securing access to the local server includes user authentication.
• the invention also relates to a system for customizing a Web application, comprising a terminal of a user having a browser comprising means for sending a request according to a data transfer protocol to a remote server hosting the application.
• application and means for receiving and executing on the user's terminal the result of the processing of the request by the remote server said system being characterized in that it comprises a local server specific to the user associated with the terminal, hosting at least one program for personalizing the application and / or personalization data of the application, and means for mixing the web application provided by the remote server with the personalization program and / or the personalization data hosted on the local server specific to the user.
• the mixing means are integrated in the terminal browser.
• the mixing means are integrated in the remote server.
• the local server comprises a web server embedded on a portable digital device connected to the user's terminal.
• the portable digital device comprises means for securing access to the program (s) and / or data hosted by the embedded server.
• the portable digital apparatus is a smart card.
• the invention also relates to a portable digital device comprising an integrated web server designed to communicate with a client according to a data transfer protocol, characterized in that the integrated server hosts at least one program and / or personalization data of a application hosted by a remote application server and includes means for providing access to the program (s) and / or personalization data of the application upon client request.
• the integrated server communicates with a browser of a terminal of a user acting as a client, through which the application runs on the terminal of the user.
• the apparatus comprises means for securing access to the program (s) and / or personalization data of the application.
• FIG. 1 illustrates the architecture of FIG. a system for implementing custom web applications according to the invention.
• the browser 40 of the user terminal also comprises means for receiving and executing on the terminal, the result of the processing of the request by the remote server, in order to display the corresponding page and thus to allow the user to continue to interact. with the application from the displayed page.
• the system according to the invention mainly consists in providing means for implementing the customization of the requested Web application, so that it is thus best suited to the specific needs and characteristics specific to the user, by building the custom web application as an application mixing (or aggregating) portions of the application from the remote web server 10 and others, i.e. the program portions and application personalization data from a user-specific local web server associated with the user's terminal.
• the programs and personalization data specific to each user of the application are deployed and hosted at the level of Web servers specific to each user, rather than in a centralized database present on the server.
• Web application as is classically the case. This characteristic, as will be seen later, makes it possible to obtain a decoupling in the deployment and implementation of personalized Web applications, in the sense that the processing related to personalization can be advantageously decoupled from the processing carried out by the client.
• Web server of the application to build on request a page of the application.
• the web server 20 specific to each user, intended to host the customization program (s) and the personalization data of the application specific to the user is made in the form of a server.
• Web embedded in a portable digital device 50 such as a smart card, a smart Multimedia Card (MMC), a USB key (“Universal Serial Bus”) smart or a mobile phone for example.
• MMC smart Multimedia Card
• USB key Universal Serial Bus
• This embodiment then imposes on the user, carrying the card 50 integrating the local web server 20 and wishing to implement the customization of an application accessed, to connect his card 50 to the host terminal 30 through which he access, through the browser, to the application provided by the remote web server 10.
• IP, TCP, HTTP / FTP / ...) these are standard Internet protocols allowing the host terminal 30 to address the card 50 as a ordinary server.
• the portable device 50 is preferably equipped with means for securing access to data hosted on its integrated server, for example means for authenticating the user carrying the device, in order to authorize access only if the user whose personalization data is hosted on the local server is recognized.
• the remote web server 10 thus provides the web application, while the portable device 50, via its embedded web server 20, is intended to provide the personalization program (s). as well as the personalization data of the application.
• the implementation of the customization of the application is then carried out by mixing (or aggregation) of the personalization program and personalization data provided by the onboard local server 20 with the application data provided by the remote server 10 and corresponding to the processing of the request issued by the browser of the user terminal for access to a page of the application.
• the mixing between the web application and the customization will be described in more detail later in the description.
• the described architecture makes it possible to decouple the deployment of the programs and personalization data from the deployment of the Web application in its remote server, since the portable device of the user is used here as the local server of the programs and personalization data.
• This architecture advantageously allows the application to operate even in the absence of customization, and change the customization without necessarily modifying the processing performed by the server.
• the proposed architecture will allow to be able to evolve and adapt the customization with a lot of flexibility, since the programs and personalization data relating to the application are no longer directly related to the processing performed by the server.
• the personalization will be able to evolve, to enrich or simplify itself, independently of the application, but also to be able to adapt, being for example more or less rich, to the content of the application on the one hand, and the environment in which the application is running, for example to take into account that it is a workstation or a mobile phone.
• a first mixing mode is to execute the customization program by the card 50, on request from the remote server 10. More specifically, the remote server 10 serves the pages of the requested Web application, and requires the Web server 20 of the the user's card 50 personalization operations whose results are interpreted by the remote server 10 to be integrated into the final page returned by the remote server.
• This embodiment where the mixing is performed via the remote server however requires that the card is accessible remotely from the remote server via the telecommunications network and also has the disadvantage of increasing the workload servers application.
• a preferred embodiment consists in mixing the application parts from the remote application server 10 and the personalization-related parts coming from the local server 20, locally via the browser 40 of the user terminal 30 by the user. through which the application is accessed.
• the host terminal browser-based mixing mode relies on Web technologies that build richer, more responsive, and more dynamic Web applications. These advanced applications allow the user to have a Web application that no longer presents itself as a succession of HTML pages (for example, consecutive to "clicks" on links) but as real desktop applications with an interface (or a "page" main or even unique) that changes as the actions of the user. Outside server queries
• JavaScript which is a programming interface (or API) available in JavaScript to execute HTTP requests to a web server synchronously or asynchronously and this in the background, that is to say without the browser loads the results to this query as a new HTML page to display.
• the results of this query often but not necessarily expressed in XML, can then be manipulated by the JavaScript program;
• the method of mixing the Web application with the programs and personalization data in the user's browser is therefore based on the one hand, on the use of a Web server specific to each user, embedded in a device portable digital device such as a smart card and hosting the programs and personalization data of the user and, secondly, on the technologies and patterns described above to execute the personalization programs and pass on their results as well as the data of the user. customization on the pages of the application displayed by the browser. This mix allows decoupled custom web applications, whether or not these web applications are advanced.
• ex-post mixing it is meant that the mixing is performed after the generic data relating to the application is provided to the browser by the remote server. This type of ex-post mixing is thus to put in opposition with the ex-ante mixing, that is to say done before the application is provided to the browser, resulting from the embodiment described above where the mixing is performed via the remote web server of the generic application.
• the first example concerns the implementation of the personalization of the application via UserScripts provided by the portable device, for example a smart card, and via requests to the card issued by the browser.
• the programs and personalization data are therefore UserScripts stored at the user's card level and are accessible via the web server integrated in the card.
• the UserScripts of the card can be installed and saved in the user's browser.
• a RegisterPersonalUserScript operation is added to GreaseMonkey.
• the user triggers this operation, which connects to the web server of the user's card, itself connected to the host terminal.
• the connection to the local server of the card can be performed with user authentication data provided by the latter, so as to allow the connection to the server only if the authentication has been successful.
• the operation then installs the UserScripts in the browser.
• the UsersScripts provided by the card are accompanied by the address book diagrams of web pages to which they apply and saved with them to GreasMonkey.
• the corresponding UserScript is mixed with the application in the browser by being executed and thus realizing the customization of the page of the application according to the operations that are coded within it.
• This UserScript can also send requests to the web server of the card (for example, via XMLHttpRequest), to dynamically recover personalization data specific to the user, which are used to achieve the customization of the page. Access to this data can also be secured by user authentication or by a diversification of the data access keys specific to the current session.
• This data can be formatted in XML or any other format that the UserScript code expects to process.
• the UserScript can not only retrieve data from the user's map but can also retrieve data from other web servers on the network. This UserScript can also download JavaScript programs from the user's map via the "On-demand JavaScript" design pattern.
• a second embodiment is provided concerning the customization via JavaScript programs provided by the card and / or via requests to the card.
• the HTML page of the application provided by the remote web server contains requests to load JavaScript programs to the card. Such a request is written on the application page by a standard HTML directive.
• the application page "appli_l" contains the directive given below as an example, which will request the loading from the local web server of the map of the personal script.
• this script containing for example the customization program in the form of a single function called customize ().
• customize A multitude of functions can nevertheless be contained in the personalization script and the personalization program itself can be provided under the form of several scripts each containing functions.
• the application's page When the application's page is loaded by the user's browser from the remote server, it is interpreted by the browser that executes the requests to load JavaScript programs encountered, from the local server on the card.
• the personalization programs stored in the map as JavaScript programs are mixed with the application code in the browser.
• These JavaScript programs are subsequently executed for example by including the following directive in the application page.
• the JavaScript functions provided as customization programs by the local server integrated in the card can be executed by any other means for executing JavaScript programs within an HTML page, such as the reaction of an event (a click of the user, the mouse of the user passing over an element of the HTML page, etc.).
• JavaScript programs above can, as in the case of the UserScripts described above, send requests to the web server of the card to dynamically recover personalization data specific to the user, which are used to perform the customization of the page. All operations involving the user's card (downloading JavaScript customization programs, queries to personalization data) can be secured by user authentication.
• a more limited way to achieve customization in the browser is simply to include in JavaScript programs provided by the application itself queries (eg via XMLHttpRequest) to the web server of the card to dynamically recover personalization data specific to the user, which are used to customize the page.
• Cross-domain security policy (“Cross-domain security policy”). It should be noted that the UserScripts used in the previous exemplary embodiment are not subject to this cross-domain security policy. This policy states that JavaScript programs on an HTML page can only come from the same server that served the page itself. Similarly, requests
• XMLHttpRequest can only be at the destination server that served the page.
• the embodiment as described here for mixing applications and customization must therefore overcome these problems in order to be implemented. Different (combinable) solutions are possible and are listed below.
• some browsers like Internet Explorer, allow to configure this policy by the user.
• the configuration can be based on the address of the remote server site, on an explicit request whenever this case arises (with the possibility to authorize until further notice), or on the presentation of certificates.
• the domain pages corresponding to the remote server site providing the application may be allowed to load JavaScript programs from the user's card and to send XMLHttpRequest requests to the user's card.
• an evolution of the browsers could allow the card itself to provide or not these JavaScript programs or to answer XMLHttpRequest requests according to the origin of the page, its certificates, or even according to a procedure of authentication between the card and the remote server (via the browser or directly between the card and the remote server via the Internet), to establish or not the trust.
• This last example of implementation is equivalent to the previous one except that the Web application is this time served by the card itself rather than by a remote server. All other features of the previous exemplary embodiment are unchanged.
• the advantage of this approach is to make the web application always available, even when the user's browser is not connected to the Internet.
• the other thing is that there is no more cross-domain security policy problem since all parts of the application, including its customization, are provided by the same server, namely the card.
• the decoupling between the application and its customization is well preserved, since they are always disjoint programs and data that are mixed in the browser of the host terminal, thus unloading the application server, that is to say the card in this embodiment, of this work, and still allowing to independently evolve the personalization of the application.
• the entire application is not served by the local server of the user's card, but only a minimal part of it allowing him to work offline (without all the features).
• additional parts of the application are downloaded from a remote server and mixed in the browser in the same way as in the previous example where the application and the customization were mixed.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Databases & Information Systems (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Data Mining & Analysis (AREA)
• Software Systems (AREA)
• Information Transfer Between Computers (AREA)
• Stored Programmes (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=36599088

Family Applications (1)

Country Status (4)

Families Citing this family (34)

Citations (1)

Family Cites Families (17)

• 2006
  • 2006-12-20 EP EP06830739A patent/EP1969461A1/de not_active Withdrawn
  • 2006-12-20 US US12/438,693 patent/US20100070566A1/en not_active Abandoned
  • 2006-12-20 KR KR1020087018596A patent/KR100966665B1/ko not_active Expired - Fee Related
  • 2006-12-20 WO PCT/EP2006/069966 patent/WO2007074119A1/fr not_active Ceased

Patent Citations (1)

Also Published As

Similar Documents

Legal Events