WO2007010139A2 - Procede et dispositif d'interaction entre des applications informatiques et un site distant - Google Patents

Procede et dispositif d'interaction entre des applications informatiques et un site distant Download PDF

Info

Publication number
WO2007010139A2
WO2007010139A2 PCT/FR2006/001771 FR2006001771W WO2007010139A2 WO 2007010139 A2 WO2007010139 A2 WO 2007010139A2 FR 2006001771 W FR2006001771 W FR 2006001771W WO 2007010139 A2 WO2007010139 A2 WO 2007010139A2
Authority
WO
WIPO (PCT)
Prior art keywords
client
event
server
objects
process according
Prior art date
Application number
PCT/FR2006/001771
Other languages
English (en)
Other versions
WO2007010139A3 (fr
Inventor
Nicolas Korboulewsky
Original Assignee
Cybertronique Sa
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from FR0507634A external-priority patent/FR2888965B1/fr
Priority claimed from FR0511123A external-priority patent/FR2892836A1/fr
Application filed by Cybertronique Sa filed Critical Cybertronique Sa
Priority to EP06778890A priority Critical patent/EP1904939A2/fr
Publication of WO2007010139A2 publication Critical patent/WO2007010139A2/fr
Publication of WO2007010139A3 publication Critical patent/WO2007010139A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/451—Execution arrangements for user interfaces
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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
    • G06F16/958—Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking

Definitions

  • the present invention relates to a method and a device for interaction between computer applications and a remote site.
  • the present invention is in the field of computing related to computer networks, for example Internet and other networks implementing the IP protocol, acronym for Internet Protocol for Internet Protocol.
  • IP protocol acronym for Internet Protocol for Internet Protocol.
  • the present invention sets up a system for communication and translation, or conversion, of data between an application, or any computer program, for example a word processor or a spreadsheet and a server hosting sites of the web, for the purpose of the display of data on the pages of these sites, the display itself being known in the prior art.
  • Site content management known as CMS, an acronym for the Content Management System or Content Management System
  • CMS Content Management System
  • the CMS content manager does not act on the structure supporting the content of the site but only on the content of the pages of the site.
  • One of the aims of the present invention is to delete this intermediary in order to be able to change the content of a website no longer through interfaces displayed by browsers but from a third-party application, for example a word processing software, a spreadsheet, presentation editing, accounting or drawing software.
  • a third-party application for example a word processing software, a spreadsheet, presentation editing, accounting or drawing software.
  • Document FR 2797336 is known from the same inventor as the present invention, which describes a method of modeling Internet sites.
  • this method is limited to defining encapsulation of functionalities in the form of objects, said objects being limited to the content of the pages of the site and not extending to all the components of the site.
  • the present invention aims to extend this object model to control, with a third-party application, the management of web sites.
  • no object is accessible programmatically from another program, but only through a user interface.
  • the present invention aims, according to a first aspect, a method of interaction between computer applications and a remote site, characterized in that it implements elements representative of the contents of the pages and the structure of the sites Web in databases located on a central server, said representative elements consisting of:
  • an object being an autonomous entity encapsulating functions for generating computer code interpretable by a client navigation application, attributes of said objects, said attributes being modifiable parameters for constituting the interface of the object with respect to the user of the client applications,
  • structure data defining the manner in which the objects are positioned in a page as well as the structure of the different pages of sites between them, the method comprising:
  • a step of generating an object macro consisting in linking objects coming from the third application in a macro object, each object of the object macro being inseparable from the other objects constituting the object macro.
  • elements from a third party application for example a word processor or a spreadsheet are implemented by the server, as objects, the links between them being stored in the macro object.
  • the present invention extends the object model described in the document FR 2797336, previously limited to the components of the pages, to all the elements of a site (sections, events, elements of the CMS content manager, etc.) as well as to the different people in charge of management and control.
  • the method as succinctly set forth above also includes, when accessing the site by a client application, a step of translating the objects of the web sites to the client elements.
  • the elements of the first third application are recoverable in another client application.
  • an array generated by a spreadsheet is translated into an object and inserted into a page of a web site and then retrieved in a word processing application, possibly automatically, without the intervention of the user of the client machine.
  • the method as succinctly set forth above also comprises a step of modeling all the elements of an Internet site through distributable objects that are accessible remotely by implementing protocols. standard. Thus, it is no longer only the contents of the pages that are modeled through objects, but also all the other elements constituting a site of the web.
  • the method as briefly described above comprises, in addition, a step of defining a generic system for remote exposure of site control objects, by their methods and properties, by implementing a web services layer used as a communication and control protocol.
  • the present invention extends the object description model not only to the contents of the pages but to the description of the entire site.
  • a site is defined as a structured set of pages.
  • the server has no knowledge of this structure, it only transmits the files it is asked. Neither does it have knowledge (in the form of a data structure) of the content of the pages and any other system.
  • the structure of the pages and their interrelationships, as well as their contents form a set of objects that can be modified.
  • the description by object extends to topics, sites, interactions between objects at the client script level, to the data objects and their contents, to the contributor and verifier users, to the rules of the client. interactions between contributors and the site, interaction rules between contributors and verifiers and script modules.
  • the present invention therefore particularly applies to the work of the site designer and to all users interacting with the site at the design and update level. However, it also improves content retrieval by site users for use in different computer applications, as discussed below.
  • the object definition of the pages extended to its containers (as we have seen previously, objects encapsulating functions to generate a computer code interpretable by a client navigation application, make it possible to represent the set of information of a site in the form of a data structure.
  • the principal structures can be seen in the form of "container", that is, a site contains pages, they themselves contain objects containing properties - in this case, the containers refer to the higher level structure, ie sites and / or a set of sites in the form of a customer account) and interactions (events and actions associated with the items in the topic, such as mouse clicks or keyboard entries) in a form, also object, and
  • the meeting of a set of objects consists of an object of the array type and Simple Text objects constituting the cells.
  • the objects of this set of objects are indissociable because each, taken individually, has no meaning outside this context, so we define an object macro named "WHOLE", which allows us to preserve the relations between the objects, here the cells and the table,
  • the server is connected to the Internet network which allows its accessibility by the client applications containing the dynamic translator (customer elements to objects of the site, and vice versa).
  • the dynamic translator can be implemented in any application and constitutes its 'Framework', that is to say all the elements making up the translation solution, or conversion.
  • the control mechanisms of the server with respect to all the other aspects, are accessible by methods on the different objects corresponding to the controls.
  • the present invention therefore makes it possible, by virtue of its total object representation and its accessibility via the web, to fully control not only the content of a site but also its structure by the manipulation of the public objects and methods that constitute its control interface.
  • interface has at least two meanings, one of which, concerning the present invention, may be a program allowing interaction with the user, or functions allowing programs to interact with each other (example API Application Program Interface).
  • the present invention makes it possible, for example, by including the dynamic translation mechanism (script or other) in an application such as Microsoft Word (registered trademarks) to directly publish content from the Word document to the website without the end user implements tools other than the software (Word itself) implementing the present invention and the client application, here Word.
  • Word implemented a scripting mechanism that allows you to add functions to the program without having to recompile the program.
  • Excel or Openoffice registered trademarks
  • the present invention aims to define, in addition to a general model of the objects constituting a website, an open model of objects that can be integrated into the website. This is to define a generic interface for objects that can be designed outside the servers and be integrated. These objects, which are materialized in the form of portable format files, for example the XML (acronym for Extensible Markup Language for Extended Markup Language), will allow the enrichment of the platform from external contributions.
  • the present invention also relates to a method and an information processing device. It applies, in particular, to the treatment of events between a Web client, for example a browser, and a server using standard web technologies, the http protocol (acronym for Hyper Text Transfer Protocol for hyper text transfer protocol).
  • DOM is the acronym for "Document Object Model” for document object model.
  • the DOM is, for browsers, an internal object representation allowing a script, like Javascript (registered trademark), to interact with the memory representation of the HTML code (acronym for HyperText Markup Language for language with hypertext links), and thus of dynamically modify the page, the web server allowing the execution of script, as well as the object modeling of a website.
  • event means the intervention of a user on the graphical interface of a browser software or browser or any other asynchronous action to the program such as the arrival of data or the end of a timer or "timer"". For example, this action is created by moving the mouse, pressing one of the mouse buttons, or pressing a key on the keyboard.
  • the application of the Internet called web operates on the basis of a client or browser, a server hosting the content to provide the client and a network for communication between the client and the server.
  • Protocols involved in the exchange of information between the client and the server include the http protocol. The latter does not make it possible to process a complex event system. The ability of this protocol to handle events is summed up as a GET or POST request that calls a new page to be loaded on the client by passing a set of field / value pairs.
  • This very simple client event processing support does not satisfy the realization of complex and highly interactive applications. Two major obstacles impede the proper functioning of such applications, firstly the full reloading of a page at each event causes graphic inconvenience for the user and behavior of the application that does not comply with the standards of the usual applications, on the other hand it is impossible to process very fast events such as moving the mouse through this system. Indeed it is not conceivable to send a request to the server for each movement of the mouse.
  • the present invention aims to remedy these disadvantages.
  • the present invention is based on a representation of the content of site pages by objects, as disclosed in document FR 2797336, of the same inventor as the present invention and incorporated herein by reference, as to its ability to model a website as an object set.
  • This document proposes a semantic extension of the DOM structure of browsers.
  • the present invention aims to obviate these drawbacks or impossibilities by proposing a new event management system between a client and a server using the standard technologies of the web (HTTP protocol, Client supporting the DOM level 2 and javascript, Web server allowing the script execution), as well as the website modeling disclosed in document FR 2797336.
  • This technology implements elements representative of the contents of the pages and the structure of the websites in databases located on a central server, said representative elements being constituted:
  • an object being an autonomous entity encapsulating functions for generating computer code interpretable by a client navigation application
  • the present invention aims, according to a second aspect, an information processing method, characterized in that it comprises:
  • a step of managing this event for at least a part of the detected events, a step of managing this event, symmetrically, on the one hand, by a client process and, on the other hand, by an asynchronous server process to the client process.
  • the implementation of the present invention allows response times of the instant application insofar as the processing of the server does not lead to changes in the content of the graphical interface.
  • the capture of the events is done relatively to the objects, for example the objects defined in the document FR 2797336, and the action that may result from the processing by the server of this event. acts on the rendering of this same type of object or other actions of treatment.
  • the processing of each event by the server does not result in the reloading of a page being displayed by the browser, unless the reloading is explicitly required by the client terminal.
  • the method as briefly described above includes a step of processing, in the client terminal, any event detected to trigger either a direct action, action that does not require processing by the server, on an object the client interface, either storing data representative of the event, in a simple event stack, or the storage of data representative of the event, in a complex event stack.
  • Complex events are events that contain additional information to the event itself. For example, the event 'onmoumouve' when The mouse moves, is a simple event, but Onmousmouve (x, y) 'with x and y the coordinates of the mouse at the time of the event, is a complex event.
  • the method as briefly described above includes, for the events stored in the stack of simple events, a step of transmission to the server.
  • the transmission step is performed via a simple http request of type GET.
  • the method as briefly described above includes, for the events stored in the complex event stack, a step of serializing the data representative of the complex event and a step of transmitting serialized data to the server. .
  • the method as succinctly set forth above includes, for the events transmitted to the server, a storage step, by the server, in at least one database associated with the stacks.
  • the method as briefly described above comprises a step of generating a request for processing the events stored in each database, through an event handler.
  • the method as briefly described above comprises, at the level of the event manager, a step of dynamic generation of a client script and a step of transmission, by the server, of said client script to the client terminal .
  • the method as briefly described above includes a step of action, in the client terminal, client script on client objects to modify the rendering.
  • the method as briefly described above comprises a step of managing the following four types of events: i. client-client, direct action of an event on a client object on another client object or itself, ii. client - simple synchronous server, standard DOM event not involving other information than the receiver object identifier and the name of the event, requiring server processing whose result modifies the graphical rendering of the client interface, iii . client - complex synchronous server, non-standard DOM event or require more information than for point ii and iv. client - synchronous client / client - complex asynchronous server, standard or non-DOM event that has both a direct action on the client interface and server processing whose result does not interfere with the client-client action.
  • FIG. 1 represents, schematically, the global architecture of a device implementing the present invention
  • FIG. 2 represents, schematically, a detail of implementation of the present invention
  • FIG. 3 represents, schematically, an example of implementation of the method which is the subject of the present invention
  • FIG. 4 represents the functional diagram of the method. information processing and event object of the second aspect of the present invention.
  • - “layer” As the OSI model defines the communication between applications by a certain number of layers communicating with each other, we implement here a protocol that exchanges information between the communicating layer and the adjacent layers (above and below); - "web services”: since web services is a known and public technology, the term web service layer means that we can use web services in the transport and control layer to invoke methods on remote objects through the http protocol, for example; "Macro object” or “object W.H.O.LE. "Macro” meaning "encompassing", a macro object is the representation of an object containing a set of objects;
  • Translation or “conversion”: They consist of moving from one representation to another by deterministic means.
  • a compiler is a translator of an X language to a Y language.
  • the data structure of the application is translated to a data structure compatible with the objects defined in the patent FR2797336.
  • an Excel table which is a container of cells, objects referring to simple texts
  • Encapsulation making it inaccessible to an end user, the source code of the object but to allow access to the functions of said object and the "clients” are, in a generic way, any software interacting with the server.
  • the clients are third-party programs other than web browsers interacting with the server;
  • Client elements In a third-party client-server architecture, there is a server and a client, the client being the program that communicates with the client, the client elements are the data that are in this program. For example, items that are processed by an Excel program; - "contributor”: any natural person who may modify the content of a duly authorized site;
  • V.D.O.M. Autonomous entities encapsulating functions to generate computer code interpretable by a client navigation application, each object having attributes, modifiable parameters making it possible to control the rendering of the interface of the object with respect to the user of the objects. client applications. It is observed that structure data external to the objects V.D.O.M. define how objects are positioned in a page as well as the structure of the different pages of sites between them. The skilled person can refer to document FR 2797336 to better know these objects.
  • patent FR 2797336 The implementation of the present invention is based on that described in patent FR 2797336 and the additional or competing technologies that have been described since the filing of this patent.
  • the part of the system described in patent FR 2797336 is used which makes it possible to transform an object representation of a site towards pages that can be used by a standard http server.
  • One of the objects of the present invention is to replace the interaction of the man with the server, through a browser, to build or modify a site via another software that is not intended originally to produce any content for the web.
  • patent FR 2797336 teaches a method of interaction between computer applications and a remote site, which implements elements representative of the contents of the pages in databases located on a central server, said representative elements being constituted:
  • an object being an autonomous entity encapsulating functions for generating computer code, for example HTML, interpretable by a client navigation application, of attributes of said objects, said attributes being modifiable parameters to constitute the interface of the object with respect to the user of the client applications and structure data defining the manner in which the objects are positioned in a page as well as the structure of the different pages of sites between them.
  • the device that is the subject of the present invention implements the Internet network and uses standard protocols: the HTTP protocol is the Hyper Text Transfer Protocol or the hyper text transfer protocol.
  • the SOAP protocol is the Simple Object Access Protocol or simple protocol for access to objects.
  • the complete object model of a site respects the object paradigm and supports at least the main characteristics, it follows that its implementation must be implemented using an object language or, at least, support the principles in the case of manipulation thereof through a network for the transmission of their components by a standard protocol, for example the Internet.
  • the present invention also proposes a system for dynamically translating a set of elements contained in the source application into an object representation by a reversible dynamic translation and it also proposes to keep this representation in the form of a WHOLE macro object. each object is inseparable from others.
  • FIG. 1 gives the overall diagram of a particular embodiment of a device that is the subject of the present invention, in which an application server 100 comprises:
  • SOAP in the prototype developed by the inventor, a mechanism to do this is the web services, but there are others like the RPC-XML
  • a response generator 125 that can, as the case may be, return a macro object W.H.O.L.E. towards the client or a response to a control action, which response is serialized and transmitted via a network 140, for example the Internet.
  • a client part is constituted on the one hand by a client application 155 (any program) or an application server 160 in which one has added, either by script if the application authorizes it, or directly in the main program application, logic, or mechanism, translation, burial, serialization, and reciprocal translation and control logic, the optional serialized flow signature system 170, and the standard protocol transport layer 175 (for example SOAP or web services).
  • client application 155 any program
  • application server 160 in which one has added, either by script if the application authorizes it, or directly in the main program application, logic, or mechanism, translation, burial, serialization, and reciprocal translation and control logic, the optional serialized flow signature system 170, and the standard protocol transport layer 175 (for example SOAP or web services).
  • the translation mechanism 165 of the elements to be transferred is invoked and generates a macro object W.H.O.L.E. containing a set of objects V.D.O.M. elementary elements describing the element or elements to be transferred.
  • This object macro is then serialized and, optionally, signed by the signature system 170.
  • the control mechanism 165 (the control being performed by the invocation of one or more methods) initiates a control sequence represented by the arrow 180 which forms a session intended to insert, represented by the arrow 185, the macro WHOLE object in the website (these commands can range from the simple request to include the object macro in a page to the creation of a new page with inclusion of this object or other actions even more complex).
  • the control methods 120 act on the object model
  • the mechanism of inclusion of the macro-object in the target page operates and a response, represented by the arrow 190, is generated by the response generator 125 and is transmitted to the client application by the standard protocols.
  • the actions are as follows: the control system of the client part (the commands are materialized by calls of functions or methods, when they are linked to an object, this is the function that is called on the server) requests the recovery of the WHOLE object, it is generated by the response generator 125, serialized and transmitted to the client application, the dynamic translation system 165 transforms each VDOM object into elements compatible with the client application 155. The result is then available in the client application 155. It is observed that there may be a translator for each client application.
  • FIG. 2 presents, in detail, the operation of a transfer sequence of the device illustrated in FIG. 1. Therefore, on a workstation 200, an original client application 205 that contains a certain number of elements 210 to publish on the web, the dynamic translator 165 analyzes the elements to be transmitted and transforms them into a set of elementary objects VDOM 220, in a macro object W.H.O.L.E. 230. In order to be transmissible over the network, this object macro is serialized by a serializer 225 and then transmitted using a standard protocol to the standard and compatible application server 100. The application server 100 then creates the series of objects transmitted, in a section 240 defined by the control mechanisms previously seen.
  • three objects are outside the object macro 230, to indicate that the field in which the object macro 230 is inserted may not be empty before the insertion of this object macro 230.
  • the dynamic translator 165 converts or translates the local data into a set of data that describes the contents of the application as a set of VDOM objects to be able to transmit them to the server and that the server reconstructs this data structure on the server 100.
  • the translator 165 produces an object macro 230 which combines the set of objects 220 into a coherent set which preserves the fact that each elementary object 220 depends on the other objects of the same object macro 230. This representation must then be sent via the network 140. It is here that the serialization mechanism 225 intervenes which transforms this representation into a sequence of characters that one can transmit over the network 140. At its other end, that is to say on the server 100, this data structure is reconstructed to keep it in a database and then use it to generate web pages as a presentation. in the patent FR 2797336.
  • the set of elementary VDOM objects 220 created are, however, maintained by a link between them defining precisely a WHOLE object 230. None of these objects can be dissociated from the others and, for example, an attempt to delete one of they will remove all others. It is therefore possible to recover, at the request of another application 255, on another workstation 250, the exact structure the system of objects transmitted by the application 205. This is done by the third application 255 which is, in the case shown in Figure 2, different from the application 205 having transmitted these data initially. When this third-party application 255 requests to retrieve a WHOLE object 230, the server 100 proceeds with the serialization of the object and then transfers it by a standard protocol to the client application 255.
  • the client application 255 deserializes the stream and then decomposes the series VDOM objects to be translated into elements compatible with the client application 255 (if possible).
  • the translator 165 then performs its work and adds, in the client application 255, the elements thus translated.
  • FIG. 3 A concrete example of this process is given in FIG. 3.
  • a spreadsheet application 205 which contains a data array 305 is observed.
  • This application 205 transmits this array 305 to the server 100.
  • the translator 165 transforms this table 305 and the data it contains into a series of elementary objects VDOM 310 which are each an object of array type 310, then a set of objects of simple text type 315, the latter containing the data of each cell.
  • These objects are then serialized and transmitted to the server 100 via the network 140.
  • the server 100 then constructs the objects locally in a page 320 defined by the control mechanism. It is then possible to publish this page thanks to the mechanisms integrated in the server 100 to obtain an HTML page.
  • the application 225 of type word processing, asks to retrieve the table 305 transmitted to the server 100 to integrate it into its current document.
  • the server 100 then serializes the objects and transmits them via the network 140. These data are then processed by the dynamic translator 165 into elements compatible with the application 255.
  • the array 325 is then reconstructed in this application 255.
  • event the intervention of a user on the graphical interface of a browser or browser.
  • this action is created by mouse movement, pressing one of the mouse buttons or pressing a key on the keyboard, or any other asynchronous action on the program such as data arrival or end of a timer.
  • a step of managing this event symmetrically, on the one hand, by a client process and, on the other hand, by an asynchronous server process to the client process.
  • the application can respond instantly since the server processing does not cause changes in the content of the GUI.
  • the capture of events is relative to the objects, for example defined in the document FR 2797336 incorporated here by reference, and that the action that may result from the processing by the server of this event acts on the rendering of this same type of object or other processing actions.
  • the processing of each event by the server does not result in the reloading of a page being displayed by the browser, unless the reloading is explicitly required by the client terminal.
  • the management of the event by the server does not affect the interactivity of the client application.
  • the event 411 is captured on a graphical interface of the client and is managed by the internal logic of this graphical interface to be then intercepted by a client object modeling dispatcher 412 which decides what actions to carry out for this event.
  • the dispatcher 412 performs a step of processing, in the client terminal, any event detected to trigger either a direct action, action that does not require processing by the server, on an object of the client interface, or the storage of data representative of the event, in a simple event stack, namely the storage of data representative of the event, in a complex event stack.
  • Complex events are events that contain additional information to the event itself.
  • the event 'onmoumouve' when the mouse moves is a simple event, but Onmousmouve (x, y) 'with x and y the coordinates of the mouse at the time of the event, is a complex event.
  • a client-client action 415 is then issued and acts on another object on the displayed page with 425 objects.
  • the action is purely synchronous with the result of the server and does not require any additional argument than the event itself and the object on which it was intercepted.
  • This event is then put into a simple first-in first out (FIFO) stack of simple events 413.
  • FIFO first-in first out
  • the browser scans this internal stack in order to transmit events to the server if there is has some in the pile.
  • the transmission of events to the server as well as the object identifier refer to is done through the ability of browsers to execute several http requests in the same instance of a browser.
  • the process used to generate this query while the page is fully charged can be multiple.
  • An HTTP "GET" request is thus made in which the contents of the stack 413, which contains the events to be transmitted, are transmitted.
  • an HTTP request is a request according to the HTTP protocol, the basic protocol for the exchange of data between a web client and a web server, for example the version of this HTTP protocol v1.0 (RFC 1945) v.1.1 (RFC 2068). It is observed, for example, in email addresses, commonly called "URL”, acronym for Uniform Resource Locator for Uniform Resource Locator, by the header "http: //". It is specified that a simple request is a request of the type "GET” followed by the uri (the uri is a subset of the uri, the one that refers to the document) that is to say 7 ⁇ document >? ⁇ data> 'which means that we pass the data directly into the query information of the document which limits the amount of data transmitted (256 characters according to the URI specifications), unlike a request of type' POST Which allows to pass data in arbitrary quantity.
  • a server script transfers the data of the request into a database 417 of the server associated with a simple event stack 419, consecutively, a request generator 424 controls the processing of the event by the server manager 421.
  • the manager server event 421 unpacks events.
  • the processing processor executes the script associated with the event. The result is the dynamic generation of a client script that performs actions on instantiated objects on the client.
  • the method that is the subject of the present invention comprises, in exemplary embodiments, a step of generating a request for processing the events stored in each said database, through an event manager.
  • the event manager performs a step of dynamic generation of a client script, a step of transmission of this client script to the client terminal, being performed by the server. It follows a step of action, in the client terminal, the client script on client objects to modify the rendering.
  • the action is synchronous with the processing on the server and requires additional parameters to the object identifier and to the name of the event, or is not a standard event supported by the DOM. this is a so-called "complex" event. Complex events are events that include information that is complementary to the event itself.
  • the event 'onmoumouve' when the mouse moves is a simple event, but Onmousmouve (x, y) 'with x and y the coordinates of the mouse at the time of the event, is a complex event.
  • This event is materialized, client-side, by a Java Script object containing a number of information bases which are the Object Identifier, the type of event, the coordinates (X 1 Y) of the object and an additional data field containing an arbitrary amount of torque (label, value ) representing the parameters specific to this event.
  • event dispatcher 412 stores the event object in the stack
  • FIFO complex events 414 At regular intervals, the browser scans the internal stack 414 to transmit events to the server, if there are in the stack.
  • the transmission of events to the server can not, in this case, be a simple http request. Indeed the http protocol can not transmit java script objects directly to the server.
  • a serializer 416 then transforms the objects of the stack 414 into a set of data transmittable by http.
  • the request generator 424 controls the processing of the event by an event manager 421 of the server.
  • the server event handler 421 depiles the events.
  • the processing processor 422 executes the script associated with the event.
  • the result is the dynamic generation of a client script 423 performing actions on the instantiated objects on the client terminal.
  • the action is synchronous to the client and asynchronous to the server processing.
  • the dispatcher simultaneously generates a direct type event intended to be processed by the server.
  • the condition for proper operation of the system is that the result of the server processing does not conflict with the Client-Client event.
  • the implementation of the present invention makes it possible to manage the following four types of events: i. client-client, direct action of an event on a client object on another client object or itself, ii. client - simple synchronous server, standard DOM event not involving other information than the receiver object identifier and the name of the event, requiring server processing whose result modifies the graphical rendering of the client interface, iii . client - complex synchronous server, non-standard DOM event or requiring more information than for point ii and iv. client - client synchronous / client - complex asynchronous server, standard event or not the DOM having both a direct action on the client interface and a server treatment whose result does not interfere with the action client - client.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Human Computer Interaction (AREA)
  • Information Transfer Between Computers (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Le procédé utilise des éléments, représentatifs des contenus des pages et de la structure des sites Web, constitués: - d'objets (220), entités autonomes encapsulant des fonctions pour générer un code informatique interprétable par une application de navigation cliente, - d'attributs desdits objets, paramètres modifiables pour constituer l'interface de l'objet vis à vis de l'utilisateur des applications clientes, - de données de structure définissant la manière dont les objets sont positionnés dans une page ainsi que la structure des différentes pages de sites entre elles. Le procédé comporte: - une étape de traduction des éléments provenant d'une application tierce (205) dits «clients» vers une représentation par objets des sites web et - une étape de génération d'un macro objet (230) consistant à lier des objets provenant de l'application tierce, dans un macro objet, chaque objet du macro objet étant indissociable des autres objets constituant le macro objet.

Description

PROCEDE ET DISPOSITIF D'INTERACTION ENTRE DES APPLICATIONS INFORMATIQUES ET UN SITE DISTANT
La présente invention concerne un procédé et un dispositif d'interaction entre des applications informatiques et un site distant. La présente invention est du domaine de l'informatique lié aux réseaux informatiques, par exemple Internet et autres réseaux mettant en œuvre le protocole IP, acronyme d'Internet Protocol pour protocole Internet. La présente invention met en place un système de communication et de traduction, ou conversion, de données entre une application, ou programme informatique, quelconque, par exemple un traitement de texte ou un tableur et un serveur hébergeant des sites de la toile, en vue de l'affichage des données sur les pages de ces sites, l'affichage lui-même étant connu dans l'art antérieur.
La gestion de contenu des sites, connue sous le nom de CMS, acronyme de Content Management System ou système de gestion de contenu, utilise actuellement une interface utilisateur de type web entre l'utilisateur et le serveur pour que l'utilisateur puisse modifier ou faire évoluer ledit contenu. Le fait qu'il y ait uniquement une interface utilisateur, donc une intervention humaine, qui permette de créer et agencer les contenus des sites constitue une limitation de l'art antérieur que la présente invention vise à éliminer. Le gestionnaire de contenu CMS n'agit donc pas sur la structure soutenant le contenu du site mais seulement sur le contenu des pages du site.
Un des buts de la présente invention est de supprimer cet intermédiaire afin de pouvoir faire évoluer le contenu d'un site web non plus au travers d'interfaces affichées par des navigateurs mais depuis une application tierce, par exemple un logiciel de traitement de texte, un tableur, un logiciel d'édition de présentations, de comptabilité ou de dessin.
On connaît le document FR 2797336, du même inventeur que la présente invention, qui décrit un procédé de modélisation des sites Internet. Cependant, ce procédé se limite à définir une encapsulation de fonctionnalités sous la forme d'objet, les dits objets se limitant au contenu des pages du site et ne s'étendant pas à toutes les composantes du site. La présente invention vise à étendre ce modèle d'objet pour piloter, avec une application tierce, la gestion de sites de la toile. En particulier, dans le système décrit dans ce document, aucun objet n'est accessible par programmation depuis un autre programme, mais seulement par une interface utilisateur.
A cet effet, la présente invention vise, selon un premier aspect, un procédé d'interaction entre des applications informatiques et un site distant, caractérisé en ce qu'il met en œuvre des éléments représentatifs des contenus des pages et de la structure des sites Web dans des bases de données situées sur un serveur central, lesdits éléments représentatifs étant constitués :
- d'objets contenus dans une base de données, un objet étant une entité autonome encapsulant des fonctions pour générer un code informatique interprétable par une application de navigation cliente, d'attributs desdits objets, lesdits attributs étant des paramètres modifiables pour constituer l'interface de l'objet vis à vis de l'utilisateur des applications clientes,
- de données de structure définissant la manière dont les objets sont positionnés dans une page ainsi que la structure des différentes pages de sites entre elles, le procédé comportant :
- une étape de traduction des éléments provenant d'une application tierce dits « clients » vers une représentation par objets des sites web et
- une étape de génération d'un macro objet consistant à lier des objets provenant de l'application tierce, dans un macro objet, chaque objet du macro objet étant indissociable des autres objets constituant le macro objet.
Grâce à ces dispositions, des éléments provenant d'une application tierce, par exemple un traitement de texte ou un tableur sont mis en œuvre par le serveur, en tant qu'objets, les liens entre eux étant mémorisés dans le macro objet. La présente invention étend le modèle objet décrit dans le document FR 2797336, précédemment limité aux composants des pages, à tous les éléments d'un site (rubriques, événements, éléments du gestionnaire de contenu CMS, etc..) ainsi qu'aux différentes personnes chargées de la gestion et du contrôle.
On rappelle ici que les rubriques sont la version abstraite des pages. Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci- dessus comporte, en outre, lors de l'accès au site par une application cliente, une étape de traduction des objets des sites web vers les éléments clients.
Grâce à ces dispositions, les éléments de la première application tierce, traduits en objets et macro objets, sont récupérables dans une autre application cliente. Par exemple un tableau généré par un tableur est traduit en objet et inséré dans une page d'un site de la toile puis récupéré dans une application de traitement de texte, éventuellement automatiquement, sans intervention de l'utilisateur de la machine cliente. Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci- dessus comporte, en outre, une étape de modélisation de l'ensemble des éléments d'un site Internet au travers d'objets distribuables et accessibles à distance en mettant en œuvre des protocoles standard. Ainsi, ce ne sont plus seulement les contenus des pages qui sont modélisés au travers d'objets, mais également tous les autres éléments constituant un site de la toile.
Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci- dessus comporte, en outre, une étape de définition d'un système générique d'exposition, à distance, d'objets de contrôles du site, par leurs méthodes et propriétés, en implémentant une couche web services utilisée comme protocole de communication et de contrôle.
On observe qu'il y a une différence entre les macro objets qui sont serialisables et transmissibles et les objets de contrôle que l'on utilise uniquement au travers de leurs propriétés et méthodes.
Ainsi, la présente invention étend le modèle objet de description non plus uniquement aux contenus des pages mais à la description de tout le site. Un site est défini comme un ensemble structuré de pages. Cependant sur un serveur http de l'art antérieur, le serveur n'a aucune connaissance de cette structure, il ne fait que transmettre les fichiers qu'on lui demande. Il n'a pas non plus de connaissance (sous la forme d'une structure de données) du contenu des pages et tout autre système. Grâce à la mise en œuvre de la présente invention, la structure des pages et leurs relations entre elles, ainsi que leur contenu forme un ensemble d'objets qui peut être modifié.
Il en résulte, sans que cette liste soit limitative, que la description par objet s'étend aux rubriques, sites, interactions entre objet au niveau script client, aux objets de données et à leurs contenus, aux utilisateurs contributeurs et vérificateurs, aux règles d'interactions entre les contributeurs et le site, aux règles d'interactions entre les contributeurs et les vérificateurs et aux modules de script.
La présente invention s'applique donc particulièrement au travail du concepteur de site et à tous les utilisateurs entrant en interaction avec le site au niveau conception et mise à jour. Cependant, elle améliore aussi la récupération de contenu par les utilisateurs du site pour les utiliser dans différentes applications informatique, comme exposé ci-après.
La modélisation du site Internet est ainsi :
- d'une part, représentée par la définition objet des pages, étendue à ses conteneurs (comme on l'a vu précédemment, des objets encapsulant des fonctions pour générer un code informatique interprétable par une application de navigation cliente, permettent de représenter l'ensemble des informations d'un site sous la forme d'une structure de données. On peut voir les structures principales sous la forme de « conteneur », c'est-à-dire qu'un site contient des pages, elles-mêmes contiennent des objets contenant des propriétés - dans le cas présent, les conteneurs font référence à la structure de plus haut niveau, à savoir les sites et/ou un ensemble de sites sous la forme d'un compte client) et interactions (les événements et actions associés aux objets de la rubrique, tels que les clics de souris ou les saisies au clavier) sous une forme, elle aussi, objet et,
- d'autre part, la réunion d'un ensemble d'objets (par exemple, la traduction d'un tableau Excel - marque déposée - est constituée d'un objet de type tableau et d'objets de type Texte Simple constituant les cellules. Les objets de cet ensemble d'objets sont indissociables car chacun, pris individuellement, n'a pas de signification en dehors de ce contexte. On définit donc un macro objet nommé « W.H.O.L.E. », qui permet de conserver les relations entre les objets, ici les cellules et le tableau,
- ainsi qu'un système de traduction dynamique entre l'application cliente et le serveur. Ce modèle, une fois instancié, possède une représentation persistante au travers de la base de données. L'ensemble des classes et des mécanismes d'accès aux objets par des protocoles standards (par exemple SOAP, acronyme de Simple Object Access Protocol pour protocole simple d'accès aux objets ou web services) sont hébergés sur un serveur applicatif.
Le serveur est relié au réseau Internet qui permet son accessibilité par les applications clientes contenant le traducteur dynamique (éléments clients vers objets du site, et réciproquement). Le traducteur dynamique peut être implémenté dans toutes applications et constitue son 'Framework', c'est-à-dire l'ensemble des éléments composant la solution de traduction, ou conversion. Les mécanismes de commande du serveur en ce qui concerne tous les autres aspects, sont accessibles par des méthodes sur les différents objets correspondant aux organes de commandes. La présente invention permet donc, de par sa représentation objet totale et son accessibilité par le web, de contrôler entièrement non seulement le contenu d'un site mais aussi sa structure par la manipulation des objets et méthodes publiques qui constituent son interface de contrôle. On rappelle que, dans le domaine informatique, le terme « interface » possède au moins deux significations, dont l'une, qui concerne la présente invention peut- être un programme permettant l'interaction avec l'utilisateur, ou des fonctions permettant à des programmes d'interagir entre eux (exemple API Application Program Interface).
La présente invention permet, par exemple, grâce à l'inclusion du mécanisme de traduction dynamique (sous forme de script ou autre) dans une application comme Microsoft Word (marques déposées) de publier directement un contenu du document Word sur le site web sans que l'utilisateur final ne mette en œuvre d'autres outils que le logiciel (Word lui- même) implémentant la présente invention et l'application cliente, ici Word. En effet, Word implémenté un mécanisme de scripting qui permet d'ajouter des fonctions au programme sans avoir à recompiler le programme. De ce fait, il est possible d'ajouter le traducteur et tous les autres programmes mis en œuvre pour implémenter la présente invention sans avoir à modifier le code source de Word et le recompiler. Excel ou Openoffice (marques déposées) présentent les mêmes mécanismes. En revanche, certains programmes de comptabilité, par exemple, ne permettent pas d'ajout et pour lui adjoindre les caractéristiques de la présente invention, il est nécessaire de modifier son code source et de le recompiler. Cet avantage s'étend à tout logiciel ou application cliente pouvant faire appel soit au protocole standard de communication, soit à des briques logicielles externes, directement, soit au travers d'un proxy (un proxy est un élément logiciel intermédiaire qui permet de faire le lien entre deux programmes applicatifs, comme une « dll » (acronyme de Dynamic Link Library pour bibliothèque de lien dynamique) dans l'environnement Windows (marque déposée).
La présente invention vise à définir, outre un modèle général des objets constituant un site Internet, un modèle ouvert d'objets pouvant être intégré au site web. Il s'agit ici de définir une interface générique pour les objets pouvant être conçu en dehors des serveurs et y être intégré. Ces objets qui sont matérialisés sous la forme de fichiers aux formats portables, par exemple l'XML (acronyme de extensible Markup Language pour langage de marquage étendu), permettront l'enrichissement de la plate-forme de part des contributions externes. La présente invention concerne aussi un procédé et un dispositif de traitement d'information. Elle s'applique, en particulier, au traitement d'événements entre un client Web, par exemple un navigateur, et un serveur en utilisant des technologies standard du web, le protocole http (acronyme de Hyper Text Transfer Protocol pour protocole de transfer hyper texte), le client supportant le DOM, niveau 2 (DOM étant l'acronyme de « Document Object Model » pour modèle d'objet de document). Le DOM est, pour les navigateurs, une représentation objet interne permettant à un script, comme Javascript (marque déposée), d'interagir avec la représentation mémoire du code HTML (acronyme de HyperText Markup Language pour langage avec liens hypertextes), et ainsi de modifier dynamiquement la page, le serveur Web permettant l'exécution de script, ainsi que la modélisation par objets d'un site Internet.
On désigne par « événement », l'intervention d'un utilisateur sur l'interface graphique d'un logiciel de navigation ou navigateur ou toute autre action asynchrone au programme comme l'arrivée de données ou la fin d'un chronomètre ou « timer ». Par exemple, cette action est crée par le mouvement de la souris, l'appui sur l'un des boutons de la souris ou l'action sur une touche du clavier. L'application du réseau Internet appelée web fonctionne sur la base d'un client ou navigateur, d'un serveur hébergeant le contenu à fournir au client et d'un réseau permettant la communication entre le client et le serveur.
Les protocoles mis en jeu dans le cadre de l'échange d'informations entre le client et le serveur sont notamment le protocole http. Ce dernier ne permet pas de traiter un système événementiel complexe. La capacité de ce protocole au traitement des événements se résume en une requête GET ou POST qui appelle une nouvelle page à être charger sur le client en passant un ensemble de couple champ / valeur. Ce support très simple de traitement des événements clients ne satisfait pas la réalisation d'applications complexes et hautement Interactives. Deux obstacles majeurs nuisent au bon fonctionnement de telles applications, premièrement le rechargement complet d'une page à chaque événement provoque un désagrément graphique pour l'utilisateur et un comportement de l'application non-conforme aux standards des applications usuelles, d'autre part, il est impossible de traiter par ce système des événements très rapide comme le déplacement de la souris. En effet il n'est pas concevable d'émettre une requête vers le serveur pour chaque mouvement de la souris.
La présente invention vise à remédier à ces inconvénients.
A cet effet, la présente invention s'appui sur une représentation du contenu des pages de site par des objets, comme exposé dans le document FR 2797336, du même inventeur que la présente invention et incorporé ici par référence, quant à sa possibilité de modéliser un site Internet comme un ensemble d'objet. Ce document propose une extension sémantique de la structure DOM des navigateurs.
La présente invention vise à obvier à ces inconvénients ou impossibilités en proposant un nouveau système de gestion événementiel entre un client et un serveur en utilisant les technologies standard du web (Protocole http, Client supportant le DOM niveau 2 et le javascript, serveur Web permettant l'exécution de script), ainsi que la modélisation de site Internet exposée dans le document FR 2797336. Cette technologie met en oeuvre des éléments représentatifs des contenus des pages et de la structure des sites Web dans des bases de données situées sur un serveur central, lesdits éléments représentatifs étant constitués :
- d'objets contenus dans une base de données, un objet étant une entité autonome encapsulant des fonctions pour générer un code informatique interprétable par une application de navigation cliente,
- d'attributs desdits objets, lesdits attributs étant des paramètres modifiables pour constituer l'interface de l'objet vis à vis de l'utilisateur des applications clientes, de données de structure définissant la manière dont les objets sont positionnés dans une page ainsi que la structure des différentes pages de sites entre elles. Chaque propriétaire de site peut modifier, via le réseau Internet, le comportement de ces objets en agissant sur leurs attributs au travers d'un gestionnaire d'objets. Il peut aussi agencer, via le réseau Internet, ces objets librement dans au moins une page et agencer les pages entre elles en agissant sur la structure au travers d'un éditeur. La consultation par un internaute du site déclenche l'activation, sur le serveur central, d'une procédure d'élaboration de pages dynamiques par un moteur d'application, à partir des informations contenues dans les bases de données de structure et d'objets, les pages dynamiques étant ensuite interprétées par un serveur HTTP et transmises sous forme de code HTML à l'application cliente. A cet effet, la présente invention vise, selon un deuxième aspect, un procédé de traitement d'information, caractérisé en ce qu'il comporte :
- une étape de détection d'un événement au niveau de l'interface d'un navigateur mis en œuvre sur un terminal client,
- pour au moins une partie des événements détectés, une étape de gestion de cet événement, symétriquement, d'une part, par un processus client et, d'autre part, par un processus serveur asynchrone au processus client.
La mise en œuvre de la présente invention autorise des temps de réponses de l'application instantané dans la mesure où le traitement du serveur n'entraîne pas de modifications dans le contenu de l'interface graphique. II résulte de la mise en œuvre de la présente invention, que la capture des événements se fait relativement aux objets, par exemple les objets définis dans le document FR 2797336, et que l'action qui peut résulter du traitement par le serveur de cet événement agit sur le rendu de ce même type d'objet ou autre actions de traitement.
Selon des caractéristiques particulières, le traitement de chaque événement par le serveur n'entraîne pas le rechargement d'une page en cours d'affichage par le navigateur, sauf si le rechargement est explicitement requis par le terminal client.
Grâce à ces dispositions, la gestion de l'événement par le serveur ne nuit pas à l'interactivité de l'application cliente.
Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci- dessus comporte une étape de traitement, dans le terminal client, de tout événement détecté pour déclencher soit une action directe, action ne nécessitant pas traitement de la part du serveur, sur un objet de l'interface client, soit la mémorisation de données représentatives de l'événement, dans une pile d'événements simples, soit la mémorisation de données représentatives de l'événement, dans une pile d'événements complexes. Les événements complexes sont des événements qui comportent des informations complémentaires à l'événement lui-même. Par exemple, l'événement 'onmoumouve' lorsque Ia souris bouge, est un événement simple, mais Onmousmouve(x,y)' avec x et y les coordonnées de la souris au moment de l'événement, est un événement complexe.
Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci- dessus comporte, pour les événements mémorisés dans la pile d'événements simples, une étape de transmission au serveur.
Selon des caractéristiques particulières, l'étape de transmission est effectuée par l'intermédiaire d'une requête http simple de type GET.
Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci- dessus comporte, pour les événements mémorisés dans la pile d'événements complexes, une étape de sérialisation des données représentatives de l'événement complexe et une étape de transmission au serveur des données sérialisées.
Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci- dessus comporte, pour les événements transmis au serveur, une étape de stockage, par le serveur, dans au moins une base de données associée aux piles. Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci- dessus comporte, une étape de génération de requête de traitement des événements stockés dans chaque base de données, au travers d'un gestionnaire d'événements.
Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci- dessus comporte, au niveau du gestionnaire d'événements, une étape de génération dynamique d'un script client et une étape de transmission, par le serveur, dudit script client au terminal client.
Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci- dessus comporte une étape d'action, dans le terminal client, du script client sur des objets clients pour en modifier le rendu. Selon des caractéristiques particulières, le procédé tel que succinctement exposé ci- dessus comporte une étape de gestion des quatre types d'événements suivants : i. client - client, action directe d'un événement sur un objet client sur autre objet client ou lui-même, ii. client - serveur synchrone simple, événement standard du DOM n'impliquant pas d'autres informations que l'identifiant objet récepteur et le nom de l'événement, nécessitant un traitement serveur dont le résultat modifie le rendu graphique de l'interface cliente, iii. client - serveur synchrone complexe, événement non standard du DOM ou nécessitent plus d'informations que pour le point ii et iv. client - client synchrone / client - serveur asynchrone complexe, événement standard ou non du DOM ayant à la fois une action directe sur l'interface cliente et un traitement serveur dont le résultat n'interfère pas avec l'action cliente - cliente.
D'autres avantages, buts et caractéristiques de la présente invention ressortiront de la description qui va suivre, faite, dans un but explicatif et nullement limitatif, en regard des dessins annexés, dans lesquels :
- la figure 1 représente, schématiquement, l'architecture globale d'un dispositif implémentant la présente invention,
- la figure 2 représente, schématiquement, un détail de mise en œuvre de la présente invention, - la figure 3 représente, schématiquement, un exemple de mise en œuvre du procédé objet de la présente invention et la figure 4 représente le schéma fonctionnel du procédé de traitement d'information et d'événement objet du deuxième aspect de la présente l'invention.
Avant de décrire les figures, on donne, ci-dessous, des définitions qui seront utilisées dans la description.
« générique » : C'est à dire que l'on n'ait pas à modifier le programme dans le cas d'ajout de nouveaux objets au système ;
« exposition des objets » : Terme informatique désignant que les objets sont accessibles par des programmeurs tiers, en effet une application orientée objet est composée d'un certain nombre d'objets, certains servant au fonctionnement interne et sont donc non accessibles depuis l'extérieur, d'autre servant d'éléments d'interface du programme avec l'extérieur on dit qu'ils sont « exposés » ; « méthodes et propriétés » : Terminologie des langages orientés objet les méthodes sont les fonctions associées à un objet, les propriétés sont des variables associées à l'objet dont on peut connaître la valeur ;
- « couche » : Comme le modèle OSI définit la communication entre application par un certain nombre de couches communicant entre elles, nous mettons en place ici un protocole qui échange des informations entre couche communicant avec les couches adjacentes (au dessus et en dessous) ; - « web services » : le web services étant une technologie connue et publique, le terme de couche web service signifie que l'on peut utiliser les web services dans la couche de transport et de contrôle pour invoquer des méthodes sur des objets distants à travers le protocole http, par exemple ; « Macro objet » ou « objet W.H.O.LE. » : « Macro » signifiant « englobant », un macro objet est la représentation d'un objet contenant un ensemble d'objets ;
« traduction » ou « conversion » : Elles consistent à passer d'une représentation à une autre par des moyens déterministes. Par exemple, un compilateur est un traducteur d'un langage X vers un langage Y. Dans notre cas, on traduit la structure de données de l'application vers une structure de données compatible avec les objets définis dans le brevet FR2797336. Par exemple, pour un tableau Excel (qui est un conteneur de cellules, objets faisant référence à des textes simples), on traduit les données de l'application pour convertir en objets + attributs + structure. Pour Excel, on crée un ensemble d'objets liés en un macro objet qui donne cohérence vis-à-vis du serveur et évite de perdre lien entre cellules et contenus ; « enfouissement » : fait référence à l'ensemble des objets non visibles depuis l'extérieur : on ne peut avoir accès aux objets élémentaires, Ie macro objet est exposé mais pas ses éléments unitaires ;
« encapsulation » : le fait de rendre inaccessible, à un utilisateur final, le code source de l'objet mais de permettre l'accès aux fonctions dudit objet et les « clients » sont, de façon générique, tout logiciel interagissant avec le serveur. Dans le cas strict de la présente invention, les clients sont les programmes tiers autre que les navigateurs web dialoguant avec le serveur ;
« éléments clients » : Dans une architecture client-serveur n tiers il y a un serveur et un client, le client étant le programme qui communique avec le client les éléments clients sont les données qui se trouvent dans ce programme. Par exemple, les éléments qui se trouvent traitées par un programme Excel ; - « contributeur » : toute personne physique susceptible de modifier le contenu d'un site dûment habilitée ;
« vérificateur » : toute personne physique pouvant autoriser ou non la publication du contenu d'un contributeur sur le site ; « base de données » : tout système pouvant contenir des données, d'un simple fichier au serveur de données ; objets « V.D.O.M. » : des entités autonomes encapsulant des fonctions pour générer un code informatique interprétable par une application de navigation cliente, chaque objet possédant des attributs, paramètres modifiables permettant de contrôler le rendu de l'interface de l'objet vis à vis de l'utilisateur des applications clientes. On observe que des données de structure extérieures aux objets V.D.O.M. définissent la manière dont les objets sont positionnés dans une page ainsi que la structure des différentes pages de sites entre elles. L'homme du métier pourra se référer au document FR 2797336 pour mieux connaître ces objets.
La mise en œuvre de la présente invention s'appuie sur celle décrite dans le brevet FR 2797336 et les technologies additionnelles ou concurrentes qui ont été décrites depuis le dépôt de ce brevet. Dans la présente invention, on utilise la partie du système décrit dans le brevet FR 2797336 qui permet de transformer une représentation objet d'un site vers des pages exploitables par un serveur http standard. Un des objets de la présente invention est de remplacer l'interaction de l'homme avec le serveur, au travers d'un navigateur, pour construire ou modifier un site par l'intermédiaire d'un logiciel autre qui n'a pas pour vocation à l'origine de produire un quelconque contenu pour le web. On rappelle que le brevet FR 2797336 enseigne un procédé d'interaction entre des applications informatiques et un site distant, qui met en œuvre des éléments représentatifs des contenus des pages dans des bases de données situées sur un serveur central, lesdits éléments représentatifs étant constitués :
- d'objets contenus dans une base de données, un objet étant une entité autonome encapsulant des fonctions pour générer un code informatique, par exemple HTML, interprétable par une application de navigation cliente, d'attributs desdits objets, lesdits attributs étant des paramètres modifiables pour constituer l'interface de l'objet vis à vis de l'utilisateur des applications clientes et de données de structure définissant la manière dont les objets sont positionnés dans une page ainsi que la structure des différentes pages de sites entre elles.
Comme on l'observe en figure 1 , le dispositif objet de la présente invention met en œuvre le réseau Internet et utilise des protocoles standards : le protocole HTTP est L'Hyper Text Transfert Protocol ou protocole de transfert hyper texte. Le protocole SOAP est le Simple Object Access Protocol ou protocole simple d'accès à des objets. Le modèle objet complet d'un site respecte le paradigme objet et en supporte au moins les principales caractéristiques, il en résulte que son implémentation doit être mise en oeuvre à l'aide d'un langage objet ou, au moins, en supporter les principes dans le cas de la manipulation de ceux-ci au travers d'un réseau permettant la transmission de leurs composantes par un protocole standard, par exemple Internet. La présente invention propose aussi un système de traduction dynamique d'un ensemble d'éléments contenu dans l'application source vers une représentation objet par une traduction dynamique réversible et elle propose aussi de conserver cette représentation sous la forme d'un macro objet W.H.O.L.E dont chaque objet est indissociable des autres.
La figure 1 donne le schéma global d'un mode de réalisation particulier d'un dispositif objet de la présente invention, dans lequel un serveur applicatif 100 comporte :
- une représentation générale de chaque site 105 sous la forme d'objets V.D.O.M. 110 et de leurs extensions, mémorisées dans une base de données,
- un système 115 de persistance des objets pouvant garder des données, du simple fichier au serveur de base de données, de façon non volatile, - un système 130 de vérification de signature optionnel, désérialiseur (on rappelle que la sérialisation est le procédé qui transforme une représentation complexe en un ensemble de données séquentiel - en général un ensemble de caractères - que l'on peut transmettre par une liaison série c'est-à-dire octet par octet, la désérialisation est l'opération inverse et un déserialiseur est la fonction qui effectue ce travail) et séquenceur permettant d'implémenter les macros objets W.H.O.L.E. sous la forme d'objets V.D.O.M. en gardant une liaison entre eux, - d'un système 120 permettant d'invoquer des méthodes depuis le réseau sur les objets de contrôle du serveur par des protocoles standards, par exemple SOAP (dans le prototype développé par l'inventeur, un mécanisme permettant de faire cette opération est les web services, mais il en existe d'autres comme le RPC-XML),
- d'un générateur de réponse 125 pouvant, suivant le cas, retourner un macro objet W.H.O.L.E. vers le client ou une réponse à une action de contrôle, réponse qui est sérialisée et transmise par l'intermédiaire d'un réseau 140, par exemple Internet.
Une partie cliente est constitué d'une part d'une application cliente 155 (un programme quelconque) ou d'un serveur applicatif 160 dans lequel on a ajouté, soit par script si l'application l'autorise, soit directement dans le programme principal de l'application, la logique, ou mécanisme, 165 de traduction, d'enfouissement, de sérialisation et la logique de traduction réciproque et de contrôle, le système optionnel de signature du flux sérialisé 170 et la couche de transport par protocole standard 175 (par exemple SOAP ou web services).
Lorsqu'un utilisateur de l'application 155 lance un processus de transfert vers le site Internet, le mécanisme de traduction 165 des éléments à transférer est invoqué et génère un macro objet W.H.O.L.E. contenant un ensemble d'objets V.D.O.M. élémentaires décrivant le ou les éléments à transférer. Ce macro objet est ensuite sérialisé et, optionnellement, signé par le système de signature 170.
Le mécanisme de contrôle 165 (le contrôle se faisant par l'invocation d'une ou plusieurs méthodes) initie une séquence de commande représentée par la flèche 180 qui forme une session ayant pour but l'insertion, représentée par la flèche 185, du macro objet W.H.O.L.E. dans le site web (ces commandes peuvent aller de la simple demande d'inclusion du macro objet dans une page à la création d'une nouvelle page avec inclusion de cette objet ou d'autres actions encore plus complexe). Suivant ce processus, les méthodes de contrôle 120 agissent sur le modèle objet
105, c'est-à-dire l'ensemble des objets constituant la représentation d'un site, le mécanisme d'inclusion du macro-objet dans la page cible opère et une réponse, représentée par la flèche 190, est générée par le générateur de réponses 125 et est transmise à l'application cliente par les protocoles standards. Dans le cas de la récupération d'un objet W.H.O.L.E. depuis le serveur applicatif vers une application, les actions sont les suivantes : le système de contrôle de la partie cliente (les commandes sont matérialisées par des appels de fonctions ou méthodes, lorsqu'elles sont liées à un objet, c'est la fonction que l'on appelle sur le serveur) demande la récupération de l'objet W.H.O.L.E., celui-ci est généré par le générateur de réponse 125, sérialisée puis transmis à l'application cliente, le système de traduction dynamique 165 transforme chaque objet V. D. O. M. en des éléments compatible avec l'application cliente 155. Le résultat est alors disponible dans l'application cliente 155. On observe qu'il peut y avoir un traducteur pour chaque application cliente.
La figure 2 présente, en détail, le fonctionnement d'une séquence de transfert du dispositif illustré en figure 1. Partant, sur un poste de travail 200, d'une application cliente d'origine 205 qui contient un certain nombre d'éléments 210 à publier sur le web, le traducteur dynamique 165 analyse les éléments à transmettre et les transforme en un ensemble d'objets élémentaires V.D.O.M. 220, dans un macro objet W.H.O.L.E. 230 . Afin d'être transmissible sur le réseau, ce macro objet » est sérialisé par un sérialiseur 225 puis transmis à l'aide d'un protocole standard au serveur applicatif 100 standard et compatible. Le serveur applicatif 100 crée ensuite la série d'objets transmis, dans une rubrique, 240 définie par les mécanismes de contrôle vus précédemment.
En figure 2, trois objets se trouvent en dehors du macro objet 230, pour indiquer que la rubrique dans laquelle le macro objet 230 est inséré peut ne pas être vide avant l'insertion de ce macro objet 230.
Les éléments locaux à l'application 205 qui transmet du contenu vers le web n'étant pas, à l'origine, représentés d'une quelconque manière sous la forme d'objets V.D.O.M., le traducteur dynamique 165 convertit ou traduit les données locales en un ensemble de données qui décrivent le contenu de l'application comme un ensemble d'objets V.D.O.M. pour pouvoir les transmettre au serveur et que celui-ci reconstruise cette structure de données sur le serveur 100. Le traducteur 165 fabrique un macro objet 230 qui réunit l'ensemble des objets 220 en un ensemble cohérant qui préserve le fait que chaque objet élémentaire 220 dépende des autres objets du même macro objet 230. Cette représentation doit ensuite être envoyée par l'intermédiaire du réseau 140. C'est donc ici qu'intervient le mécanisme de sérialisation 225 qui transforme cette représentation en une séquence de caractères que l'on peut transmettre par le réseau 140. A son autre extrémité, c'est-à-dire sur le serveur 100, on reconstruit cette structure de données pour la conserver dans une base de données et l'utiliser ensuite pour générer des pages Web comme exposé dans le brevet FR 2797336.
L'ensemble des objets V.D.O.M. élémentaires 220 créés sont cependant maintenus par une liaison entre eux définissant précisément un objet W.H.O.L.E. 230. Aucun de ces objets ne peut être dissocié des autres et, par exemple, une tentative de suppression de l'un d'entre eux supprimera tous les autres. Il est par conséquent possible de récupérer, lors de la demande d'une autre application 255, sur un autre poste de travail 250, la structure exacte du système d'objets transmis par l'application 205. C'est ce qui est fait par l'application tierce 255 qui est, dans le cas représenté en figure 2, différente de l'application 205 ayant transmis ces données initialement. Lorsque cette application tierce 255 demande à récupérer un objet W.H.O.L.E. 230, le serveur 100 procède à la sérialisation de l'objet puis le transfère par un protocole standard vers l'application cliente 255. L'application cliente 255 désérialise le flux puis décompose la série d'objets V.D.O.M. à traduire en éléments compatibles avec l'application cliente 255 (si possible). Le traducteur 165 effectue ensuite son travail et ajoute, dans l'application cliente 255, les éléments ainsi traduits.
Un exemple concret de ce processus est donné dans la figure 3. Dans cette figure 3, on observe une application 205 de type tableur qui contient un tableau de données 305. Cette application 205 transmet ce tableau 305 vers le serveur 100. A cet effet, le traducteur 165 transforme ce tableau 305 et les données qu'il contient, en une série d'objets élémentaires V.D.O.M. 310 qui sont, chacun, un objet de type tableau 310, puis un ensemble d'objets de type texte simple 315, ces derniers contenant les données de chaque cellule. Ces objets sont ensuite sérialisées et transmis au serveur 100 via le réseau 140. Le serveur 100 construit alors les objets localement dans une page 320 définie par le mécanisme de contrôle. Il est ensuite possible de publier cette page grâce aux mécanismes intégrés au serveur 100 pour en obtenir une page HTML.
On suppose ici qu'une l'application 225, de type traitement de texte, demande à récupérer le tableau 305 transmis au serveur 100 pour l'intégrer dans son document courant. Le serveur 100 sérialise alors les objets et les transmet via le réseau 140. Ces données sont ensuite traitées par le traducteur dynamique 165 en éléments compatibles avec l'application 255. Le tableau 325 est alors reconstruit dans cette application 255.
Avant de détailler la description de la figure 4, on rappelle que l'on désigne par « événement », l'intervention d'un utilisateur sur l'interface graphique d'un logiciel de navigation ou navigateur. Par exemple, cette action est crée par le mouvement de la souris, l'appui sur l'un des boutons de la souris ou l'action sur une touche du clavier ou toute autre action asynchrone au programme comme l'arrivée de données ou la fin d'un 'timer'.
Le procédé de traitement d'information objet de la présente invention comporte : - une étape de détection d'un événement au niveau de l'interface d'un navigateur mis en oeuvre sur un terminal client,
- pour au moins une partie des événements détectés, une étape de gestion de cet événement, symétriquement, d'une part, par un processus client et, d'autre part, par un processus serveur asynchrone au processus client. Ainsi, l'application peut répondre instantanément dans la mesure où le traitement du serveur n'entraîne pas de modifications dans le contenu de l'interface graphique. Il résulte de la mise en œuvre de la présente invention, que la capture des événements se fait relativement aux objets, par exemple définis dans le document FR 2797336 incorporé ici par référence, et que l'action qui peut résulter du traitement par le serveur de cet événement agit sur le rendu de ce même type d'objet ou autre actions de traitement.
Préférentiellement, le traitement de chaque événement par le serveur n'entraîne pas le rechargement d'une page en cours d'affichage par le navigateur, sauf si le rechargement est explicitement requis par le terminal client. La gestion de l'événement par le serveur ne nuit donc pas à l'interactivité de l'application cliente.
On observe, en figure 4, que trois couches sont mises en œuvre. Ces couches sont le client C1 , le réseau Internet C2 et le serveur C3. L'événement 411 est capté sur une interface graphique du client et est géré par la logique interne de cette interface graphique pour être ensuite intercepté par un dispatcher 412 de modélisation objet client qui décide quelles sont les actions à mener pour cet événement.
Le dispatcher 412 effectue une étape de traitement, dans le terminal client, de tout événement détecté pour déclencher soit une action directe, action ne nécessitant pas de traitement de la part du serveur, sur un objet de l'interface client, soit la mémorisation de données représentatives de l'événement, dans une pile d'événements simples, soit la mémorisation de données représentatives de l'événement, dans une pile d'événements complexes.
Les événements complexes sont des événements qui comportent des informations complémentaires à l'événement lui-même. Par exemple, l'événement 'onmoumouve' lorsque la souris bouge, est un événement simple, mais Onmousmouve(x,y)' avec x et y les coordonnées de la souris au moment de l'événement, est un événement complexe.
Plusieurs cas de figure sont possibles et sont déterminés en amont par un compilateur qui analyse le code programme et génère les éléments de programmes nécessaires et, en particulier indique le cas dans lequel on se trouve.
Dans un premier cas de figure, l'action, ou l'événement, n'a pas à être traitée par le serveur et n'a d'action que sur le client, une action 415 client - client est alors émise et agit sur un autre objet de la page affichée comportant les objets 425.
Dans un deuxième cas de figure, l'action est purement synchrone au résultat du serveur et ne nécessite pas d'argument supplémentaire que l'événement lui-même et que l'objet sur lequel il a été intercepté. Cet événement est alors mis dans une pile FIFO (acronyme de First In First Out pour premier entré premier sorti) des événements simples 413. A intervalle de temps régulier, le navigateur scrute cette pile interne afin de transmettre les événements au serveur s'il y en a dans la pile. La transmission des événements au serveur ainsi que de l'identifiant objet réfèrent se fait grâce à la capacité des navigateurs à exécuter plusieurs requêtes http dans la même instance d'un navigateur. Le procédé utilisé pour générer cette requête alors que la page est complètement chargé peut être multiple. Il peut être, par exemple, initié dans une Frame (ou trame) (nouvelle instance de chargement d'une page dans le navigateur) ou par des techniques autre comme par exemple celle connue sous le nom de « remote scripting ». On effectue donc une requête de type « GET » HTTP dans laquelle on transmet le contenu de la pile 413 qui contient les événements à transmettre.
On rappelle qu'une requête HTTP est une requête selon le protocole HTTP, le protocole de base des échanges de données entre un client web et un serveur web, par exemple la version de ce protocole HTTP v1.0 (RFC 1945) v.1.1 (RFC 2068). On l'observe, par exemple, dans les adresses électroniques, communément appelées « URL », acronyme de Uniform Resource Locator pour localiseur de ressources uniforme, par l'en-tête « http:// ». On précise qu'une requête simple est une requête de type « GET » suivie de l'uri (l'uri est une sous partie de l'uri, celle qui fait référence au document) c'est-à-dire 7<document> ?<données>' ce qui signifie que l'on passe les données directement dans les informations de requête du document ce qui limite la quantité de données transmissible (256 caractères selon les spécifications des uri ), contrairement à une requête de type « POST » qui permet de passe des données en quantité arbitraire.
Un script serveur transfert les données de la requête dans une base de données 417 du serveur associée à une pile d'événement simples 419, consécutivement, un générateur de requête 424 commande le traitement de l'événement par le gestionnaire du serveur 421. Le gestionnaire d'événements 421 du serveur dépile les événements. Le processeur de traitement exécute le script associé à l'événement. Le résultat est la génération dynamique d'un script client effectuant des actions sur les objets instanciés sur le client.
Ainsi, le procédé objet de la présente invention comporte, dans des modes de réalisation exemplaires, une étape de génération de requête de traitement des événements stockés dans chaque dite base de données, au travers d'un gestionnaire d'événements. Le gestionnaire d'événements effectue une étape de génération dynamique d'un script client, une étape de transmission de ce script client au terminal client, étant effectuée par le serveur. Il s'en suit une étape d'action, dans le terminal client, du script client sur des objets clients pour en modifier le rendu. Dans un troisième cas de figure, l'action est synchrone avec le traitement sur le serveur et nécessite des paramètres additionnels à l'identifiant objet et au nom de l'événement, ou n'est pas un événement standard supporté par le DOM, il s'agit alors d'un événement dit « complexe ». On rappelle que les événements complexes sont des événements qui comportent des informations complémentaires à l'événement lui-même. Par exemple, l'événement 'onmoumouve' lorsque la souris bouge, est un événement simple, mais Onmousmouve(x,y)' avec x et y les coordonnées de la souris au moment de l'événement, est un événement complexe. Cet événement est matérialisé, coté client, par un objet Java Script contenant un nombre de bases d'informations qui sont l'Identifiant Objet, le type d'événement, les coordonnées (X1Y) de l'objet et un champ data supplémentaire contenant une quantité arbitraire de couple (étiquette, valeur) représentant les paramètres spécifiques à cet événement. Dans ce cas, le dispatcher d'événement 412 stocke l'objet événement dans la pile
FIFO des événements complexes 414. A intervalle de temps régulier, le navigateur scrute cette pile interne 414 afin de transmettre les événements au serveur, s'il y en a dans la pile.
La transmission des événements au serveur ne peut pas, dans ce cas, être une simple requête http. En effet le protocole http ne peut transmettre des objets java script directement au serveur. Un serialisateur 416 transforme alors les objets de la pile 414 en un ensemble de données transmissibles par http.
La sérialisation effectuée et le stockage de l'événement dans une base de données 418 du serveur associée à une pile 420 d'événements complexes conservée dans le serveur, le générateur de requête 424 commande le traitement de l'événement par un gestionnaire d'événement 421 du serveur. Le gestionnaire d'événements 421 du serveur dépile les événements. Le processeur de traitement 422 exécute le script associé à l'événement. Le résultat est la génération dynamique d'un script 423 client effectuant des actions sur les objets instanciés sur le terminal client.
Dans un quatrième cas de figure, l'action est synchrone au client et asynchrone au traitement serveur. Dans ce cas, le dispatcher génère parallèlement un événement de type direct destiné à être traité par le serveur. La condition pour un bon fonctionnement du système est que le résultat du traitement du serveur n'agisse pas en contradiction avec l'événement Client-Client.
Ainsi, la mise en œuvre de la présente invention permet de gérer les quatre types d'événements suivants : i. client - client, action directe d'un événement sur un objet client sur autre objet client ou lui-même, ii. client - serveur synchrone simple, événement standard du DOM n'impliquant pas d'autres informations que l'identifiant objet récepteur et le nom de l'événement, nécessitant un traitement serveur dont le résultat modifie le rendu graphique de l'interface cliente, iii. client - serveur synchrone complexe, événement non standard du DOM ou nécessitant plus d'informations que pour le point ii et iv. client - client synchrone / client - serveur asynchrone complexe, événement standard ou non du DOM ayant à la fois une action directe sur l'interface cliente et un traitement serveur dont le résultat n'interfère pas avec l'action cliente - cliente.

Claims

REVENDICATIONS
1 - Procédé d'interaction entre des applications informatiques (155, 205, 255) et un site distant (105), caractérisé en ce qu'il met en œuvre des éléments représentatifs des contenus des pages et de la structure des sites Web dans des bases de données situées sur un serveur central (100), lesdits éléments représentatifs étant constitués :
- d'objets (220) contenus dans une base de données (115), un objet étant une entité autonome encapsulant des fonctions pour générer un code informatique interprétable par une application de navigation cliente, - d'attributs desdits objets, lesdits attributs étant des paramètres modifiables pour constituer l'interface de l'objet vis à vis de l'utilisateur des applications clientes, de données de structure définissant la manière dont les objets sont positionnés dans une page ainsi que la structure des différentes pages de sites entre elles, le procédé comportant : - une étape de traduction des éléments provenant d'une application tierce (205) dits
« clients » vers une représentation par objets des sites web et
- une étape de génération d'un macro objet (230) consistant à lier des objets (220) provenant de l'application tierce, dans un macro objet, chaque objet du macro objet étant indissociable des autres objets constituant le macro objet. 2 - Procédé selon la revendication 1 , caractérisé en ce qu'il comporte, en outre, lors de l'accès au site par une application cliente, une étape de traduction des objets des sites web vers les éléments clients.
3 - Procédé selon l'une quelconque des revendications 1 ou 2, caractérisé en ce qu'il comporte, en outre, une étape de modélisation de l'ensemble des éléments d'un site Internet au travers d'objets distribuables et accessibles à distance en mettant en oeuvre des protocoles standard.
4 - Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce qu'il comporte, en outre, une étape de définition d'un système générique d'exposition, à distance, d'objets de contrôles du site, par leurs méthodes et propriétés, en implémentant une couche web services utilisée comme protocole de communication et de contrôle.
5 - Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce qu'il comporte :
- une étape de détection d'un événement (411) au niveau de l'interface d'un navigateur mis en œuvre sur un terminal client (C1), - pour au moins une partie des événements détectés, une étape de gestion de cet événement, symétriquement, d'une part, par un processus client et, d'autre part, par un processus serveur (C3) asynchrone au processus client. 6 - Procédé selon la revendication 5, caractérisé en ce que le traitement de chaque événement (411) par le serveur (C3) n'entraîne pas le rechargement d'une page en cours d'affichage par le navigateur, sauf si le rechargement est explicitement requis par le terminal client. 7 - Procédé selon l'une quelconque des revendications 5 ou 6, caractérisé en ce qu'il comporte une étape de traitement, dans le terminal client, de tout événement (411) détecté pour déclencher soit une action directe, action ne nécessitant pas traitement de la part du serveur (C3), sur un objet de l'interface client, soit la mémorisation de données représentatives de l'événement, dans une pile d'événements simples (413), soit la mémorisation de données représentatives de l'événement, dans une pile d'événements complexes (414).
8 - Procédé selon la revendication 7, caractérisé en ce qu'il comporte, pour les événements (411) mémorisés dans la pile d'événements simples (413), une étape de transmission au serveur (C3). 9 - Procédé selon la revendication 8, caractérisé en ce que l'étape de transmission est effectuée par l'intermédiaire d'une requête http simple de type GET.
10 - Procédé selon l'une quelconque des revendications 7 à 9, caractérisé en ce qu'il comporte, pour les événements (411) mémorisés dans la pile d'événements complexes (414), une étape de sérialisation (16) des données représentatives de l'événement complexe et une étape de transmission au serveur (C3) des données sérialisées.
11 - Procédé selon l'une quelconque des revendications 5 à 10, caractérisé en ce qu'il comporte, pour les événements (411) transmis au serveur (C3), une étape de stockage, par le serveur, dans au moins une base de données (417, 418) associée aux piles (419, 420).
12 - Procédé selon la revendication 11 , caractérisé en ce qu'il comporte, une étape de génération de requête (424) de traitement des événements (411) stockés dans chaque dite base de données (417, 418), au travers d'un gestionnaire d'événements (421).
13 - Procédé selon la revendication 12, caractérisé en ce qu'il comporte, au niveau du gestionnaire d'événements (421), une étape de génération dynamique d'un script client (423) et une étape de transmission, par le serveur (C3), dudit script client au terminal client (C1). 14 - Procédé selon la revendication 13, caractérisé en ce qu'il comporte une étape d'action, dans le terminal client (C1), du script client (423) sur des objets clients (425) pour en modifier le rendu.
15 - Procédé selon l'une quelconque des revendications 5 à 14, caractérisé en ce qu'il comporte une étape de gestion des quatre types d'événements (411) suivants : i. client (C1) - client, action directe d'un événement sur un objet client sur autre objet client ou lui-même, ii. client - serveur (C3) synchrone simple, événement standard du DOM n'impliquant pas d'autres informations que l'identifiant objet récepteur et le nom de l'événement, nécessitant un traitement serveur dont le résultat modifie le rendu graphique de l'interface cliente, iii. client - serveur synchrone complexe, événement non standard du DOM ou nécessitant plus d'informations que pour le point ii et iv. client - client synchrone / client - serveur asynchrone complexe, événement standard ou non du DOM ayant à la fois une action directe sur l'interface cliente et un traitement serveur dont le résultat n'interfère pas avec l'action cliente - cliente.
PCT/FR2006/001771 2005-07-19 2006-07-19 Procede et dispositif d'interaction entre des applications informatiques et un site distant WO2007010139A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP06778890A EP1904939A2 (fr) 2005-07-19 2006-07-19 Procede et dispositif d'interaction entre des applications informatiques et un site distant

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
FR0507634 2005-07-19
FR0507634A FR2888965B1 (fr) 2005-07-19 2005-07-19 Procede et dispositift d'interaction entre des applications informatiques et un site distant
FR0511123A FR2892836A1 (fr) 2005-11-02 2005-11-02 Procede et dispositif de traitement d'un evenement detecte a un niveau de l'interface d'un navigateur
FR0511123 2005-11-02

Publications (2)

Publication Number Publication Date
WO2007010139A2 true WO2007010139A2 (fr) 2007-01-25
WO2007010139A3 WO2007010139A3 (fr) 2007-04-05

Family

ID=37198978

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2006/001771 WO2007010139A2 (fr) 2005-07-19 2006-07-19 Procede et dispositif d'interaction entre des applications informatiques et un site distant

Country Status (2)

Country Link
EP (1) EP1904939A2 (fr)
WO (1) WO2007010139A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116032021A (zh) * 2023-03-30 2023-04-28 西安热工研究院有限公司 新能源场站一体化监控方法、系统、设备及存储介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2797336A1 (fr) * 1999-08-02 2001-02-09 Pyc Conseils Procede et systeme de creation, de gestion et de consultation de sites web

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2797336A1 (fr) * 1999-08-02 2001-02-09 Pyc Conseils Procede et systeme de creation, de gestion et de consultation de sites web

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
KEI SHIU HO ET AL: "A collaborative word processing system using a CORBA-based workflow framework" DISTRIBUTED OBJECTS AND APPLICATIONS, 2001. DOA '01. PROCEEDINGS. 3RD INTERNATIONAL SYMPOSIUM ON 17-20 SEPT. 2001, PISCATAWAY, NJ, USA,IEEE, 17 septembre 2001 (2001-09-17), pages 176-185, XP010560722 ISBN: 0-7695-1300-X *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116032021A (zh) * 2023-03-30 2023-04-28 西安热工研究院有限公司 新能源场站一体化监控方法、系统、设备及存储介质
CN116032021B (zh) * 2023-03-30 2023-08-25 西安热工研究院有限公司 新能源场站一体化监控方法、系统、设备及存储介质

Also Published As

Publication number Publication date
EP1904939A2 (fr) 2008-04-02
WO2007010139A3 (fr) 2007-04-05

Similar Documents

Publication Publication Date Title
US6941512B2 (en) Dynamic web content unfolding in wireless information gateways
CA2357409C (fr) Systeme de communication d&#39;un equipement d&#39;automatisme base sur le langage wsdl
EP2643961B1 (fr) Communication entre deux applications web
US8621092B2 (en) Remote portlet consumer with enhanced resource URL processing
EP1193950A2 (fr) Procédé d&#39;optimisation, par un élément d&#39;architecture de réseau, de la consulation de données.
WO2000056030A1 (fr) Systeme d&#39;acces a un objet a l&#39;aide d&#39;un navigateur de type &#39;web&#39; cooperant avec une carte a puce
MXPA06000085A (es) Puerta de refrigerador y refrigerardor con la misma.
CN112559928B (zh) 基于混合开发的页面处理方法、装置、电子设备及存储介质
WO2008113917A2 (fr) Procede permettant de simuler le fonctionnement d&#39;un dispositif ayant une architecture et un processeur determines a l&#39;aide d&#39;un autre dispositif connecte a un reseau informatique
EP1285361A1 (fr) Systeme de publication multi-terminal et procede de mise en oeuvre correspondant
EP2169569B1 (fr) Procédé et système de communication entre applications web distinctes
WO2007141446A1 (fr) Système de gestion d&#39;un service interactif multimodal
Kuuskeri et al. Partitioning web applications between the server and the client
EP2187321B1 (fr) Procédé et dispositif d&#39;édition d&#39;un objet représenté dans une page web
WO2007010139A2 (fr) Procede et dispositif d&#39;interaction entre des applications informatiques et un site distant
FR2991840A1 (fr) Procede de traitement de donnees par un module de navigation
EP2575327B1 (fr) Procédé de partage d&#39;une application web entre plusieurs terminaux informatiques reliés à un réseau de communication
FR2888965A1 (fr) Procede et dispositift d&#39;interaction entre des applications informatiques et un site distant
Rodgers Java and its future in biomedical computing
FR2827406A1 (fr) Methode generique de parcours d&#39;un arbre objets pour invoquer une methode specifique sur certains objets dudit arbre
FR2892836A1 (fr) Procede et dispositif de traitement d&#39;un evenement detecte a un niveau de l&#39;interface d&#39;un navigateur
EP2156340B1 (fr) Procede et dispositif de communication entre applications web distinctes
CN109074360A (zh) 使用多个线程减少下载电子资源的延迟
FR2853974A1 (fr) Procede de generation d&#39;une interface de communication a distance pour des informations basees sur un cadre de description de ressources (rdf)
Kirsimäe Automated OpenAjax Hub Widget Generation for Deep Web Surfacing

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2006778890

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

WWP Wipo information: published in national office

Ref document number: 2006778890

Country of ref document: EP