WO2002089446A2 - Dispositif et procede de traitement de donnees, et serveur comportant ce dispositif - Google Patents

Dispositif et procede de traitement de donnees, et serveur comportant ce dispositif Download PDF

Info

Publication number
WO2002089446A2
WO2002089446A2 PCT/FR2002/001443 FR0201443W WO02089446A2 WO 2002089446 A2 WO2002089446 A2 WO 2002089446A2 FR 0201443 W FR0201443 W FR 0201443W WO 02089446 A2 WO02089446 A2 WO 02089446A2
Authority
WO
WIPO (PCT)
Prior art keywords
data
layer
module
modules
elementary
Prior art date
Application number
PCT/FR2002/001443
Other languages
English (en)
Other versions
WO2002089446A3 (fr
Inventor
Thomas Serval
Grégoire ISSENMANN
Original Assignee
Savoirweb
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
Application filed by Savoirweb filed Critical Savoirweb
Publication of WO2002089446A2 publication Critical patent/WO2002089446A2/fr
Publication of WO2002089446A3 publication Critical patent/WO2002089446A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/12—Protocol engines
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • the invention relates to the field of data processing and more particularly that of the management of data exchanged between at least one external network, public and / or private, and user terminals, possibly integrated into an internal network.
  • This type of management is generally provided by computer servers equipped with a firewall type processing device (better known by the English word “firewall”), which protects user terminals against external intrusions, and / or of the “proxy” type, which provides filtering and / or recording of information movements and / or temporary storage (or cache).
  • a firewall type processing device better known by the English word “firewall”
  • proxy which provides filtering and / or recording of information movements and / or temporary storage (or cache).
  • the invention relates more particularly to proxy servers (or gateways).
  • proxy servers are dedicated to specific services, for example the Internet. There are, for Internet services, web proxies, ftp proxies and telnet proxies, in particular. By design, these proxy servers tolerate very little addition of functionality (or "plugin"). They cannot therefore be reconfigured to provide a service different from that for which they were designed.
  • proxies respectively under the names “Traffic Server” and "WBI", which improve the situation, insofar as one is equipped with an API type interface allowing a supervisor to communicate with him, and the other offers the possibility of adding entry points (or "hooks") allowing a supervisor to modify his behavior.
  • HTTP HyperText Transfer Protocol
  • proxies remain associated with a single protocol (HTTP), which cannot be modified, and do not allow the path followed by the data flow within them to be controlled. Therefore, any advanced use of these proxies remains impossible.
  • the invention therefore aims to solve all or part of the aforementioned drawbacks.
  • a data processing device intended to be installed in a computer server, and comprising:
  • a low-level logical layer structure for data processing, intended to be connected to one or more networks and to one or more user terminals, and comprising at least a first layer for initiating user requests intended to a network, a second layer for recovering the data streams which are transmitted by the network in response to a request initiated at the level of the first layer, a third layer for transforming the data of the recovered streams, and a fourth layer for the transmission of the data recovered and possibly transformed to the terminal of the requesting user,
  • control means provided with module interfacing means (preferably operating according to the "Java Management extension (JMX)" mode) and capable of associating with at least one of the layers at least one of the elementary modules to satisfy user requests, then configure each module associated with each layer so that it can exchange data flows, via the interfacing module, with at least one of the modules which are associated with its layer and / or to the next layer,
  • JMX Joint Management extension
  • the modules configured and associated with each layer being further arranged to add to the data of the outgoing flow that they generate an object request, which is representative of its type and which is enriched, possibly, during its passage in each of the layers, so that on reception of this flow the elementary receiving module can immediately determine whether it should process it or else the transmit, without processing, to another module, the same layer or the next layer.
  • Each low-level layer is thus responsible for managing certain processing operations carried out specifically by the elementary (or canonical) module (s) which have been associated with it and these modules constitute a kind of "black box" which exchanges data between them via a common interface. , for example API type.
  • the elementary modules can either be initially grouped into classes each associated with a predefined layer (they are then selected within their class and configured), or intended to be fully configurable to provide processing in several layers.
  • each elementary module associated with the fourth layer is arranged so as to delete the request object which is attached to a stream before it is transmitted to the terminal of the user who had sent the initial request.
  • These elementary modules are preferably chosen from a group comprising at least three modules for managing the network data exchange protocol, suitable for being selectively associated with the first, second and fourth layers, a first cache memory management module for the data recovery at at least one of the structure layers (and preferably at the second layer), a second cache management module for temporary storage of data at at least the one of said layers of the structure (and preferably at the level of the second layer and / or the third layer), a backup module for storing information data relating to the use of the device and allowing the editing of configurable logs, a first module for transforming data pages, in a chosen format , in other data pages, in the same chosen format (this may include modifying tags, removing one or more images, rewriting addresses pointed to by hypertext links, or more generally adding or to remove data), a second transformation module intended to be associated with the third layer to transform data retrieved by an elementary module associated with the second layer and placed in a first format (for example of XML type) into data in a second format (for example of the
  • the device according to the invention may also include the following characteristics, taken separately and in combination:
  • a buffer memory (possibly of dynamic circular type) for temporarily storing data which has reached the second layer and / or the third layer;
  • control means also making it possible to manage substantially simultaneously several (at least two) user requests originating from several (at least two) terminals of different users;
  • control means also making it possible to associate several times the same elementary module with the same layer, according to possibly different configurations, so that they can provide treatments in series or in parallel, identical or different;
  • control means also making it possible to manage the distribution of processing tasks, either within a multitasking server, or between multiple servers (at least two).
  • one of the servers can be provided to carry out the processing associated with one or more layers, for example the second layer (data recovery), while at least one other server is intended to carry out the associated processing. to one or more other layers, for example the third layer (transformation of the recovered data);
  • the graphic interface module can also be arranged so as to provide a user terminal, which is connected to the server in which it is installed, with information on the state of each elementary module which has been associated to a logical layer;
  • the device according to the invention is preferably installed in a computer server of the “proxy” type, or in a box (such as computer equipment), connected to one (or more) public telecommunications network (s). and / or private and to one (or more) user terminal (s), possibly on a network.
  • All its modules, and its control means can be produced in the form of electronic circuits ("hardware") and / or software modules ("software").
  • software modules at least some of them can be produced in JAVA computer language, in particular used in programming mode of non-blocking type, or else in C or C ++ computer language .
  • the invention further relates to a method of processing accounting data comprising at least the following steps: a) providing a structure with low-level logical layers for processing of data, this structure comprising at least a first layer for initiating user requests intended for a network, a second layer for recovering data streams transmitted by the network in response to a request initiated by the first layer, a third layer to transform flow data recovered at the level of the second layer, and a fourth layer to transmit the transformed data to the user who had issued a request, b) providing a multiplicity of elementary modules for applying specific treatments to flow of incoming data, according to their respective types, and for generating outgoing data flows comprising the processed data, c) associating with at least one of the layers at least one of the elementary modules to satisfy the user's request, then configure each module associated with each layer so that it can exchange data streams with one at less of the modules which are associated with its layer and / or with the following layer, and d) add to the data flow which leaves each elementary module, configured and associated with a layer, a
  • FIG. 1 very schematically illustrates an installation equipped with a proxy server according to the invention
  • FIG. 2 is a block diagram illustrating very schematically part of a processing device according to the invention installed in a proxy server
  • FIG. 3 is a diagram illustrating a method of association and configuration of modules according to the invention, adapted to a user request, in an application of the “proxy cache” type
  • FIG. 4 is a diagram illustrating a method of association and configuration of modules according to the invention, adapted to a user request, in an application of the “proxy cache” type with user authentication, and
  • FIG. 5 is a diagram illustrating a method of association and configuration of modules according to the invention, adapted to a user request, in an application of the “proxy cache” type with user authentication and data transformation recovered.
  • the device could be installed in an external box, of the auxiliary equipment type, connected to the SRM server, the latter then being directly connected to the external Internet network.
  • a user terminal can therefore, by issuing a request for access to a page of data stored in a website SWj, access this data, or in other words recover it, via the Internet, the proxy server 1 and the SRI1 server.
  • the proxy server 1 or the SRM server can optionally provide the firewall function.
  • SRI2 Other private network servers
  • SRI2 can also be connected to the public Internet network, possibly via another proxy server 10 equipped either with a processing device according to the invention, or with a standard data processing device 20.
  • a proxy server is a computer device which acts as an interface between an external network, such as the Internet, which uses a first data exchange protocol, and one or more terminals of 'users, possibly connected to a private network which uses a second data exchange protocol.
  • an external network such as the Internet
  • the computer server is called a router.
  • a proxy server generally performs at least one of the following three main functions:
  • cache the temporary storage of data, better known under the term "cache", which consists in locally preserving, in a memory suitable for this purpose, the pages which are most commonly visited by users, so as to speed up loading thereof on their terminals;
  • filtering of the data passing through it, so that only the data which correspond to the predefined (and configurable) filtering criteria are transmitted to the requesting user.
  • Any type of filtering can be considered. It can be generalized to an entire network, or to sub-parts of a network, or even adapted to each user. In the latter case, the filtering also relates to user authentication.
  • the proxy server can also provide the firewall function, in order to protect user terminals, or the private network, from attacks from the outside network.
  • the proxy server serves as an interface between the Internet network and a private network comprising an internal server SRI1.
  • the proxy server can be installed in many other places, such as for example at a service provider, or at a cable operator.
  • FIG. 2 to describe in detail a treatment device according to the invention.
  • This device comprises, first of all, a control module 3, a multiplicity of elementary processing modules, preferably stored in a memory 4, means 5 for interfacing the elementary processing modules, and a structure 6 with logic layers low level.
  • This multilayer structure 6 comprises at least four layers I, G, T and S intended to provide specific data processing.
  • Layer I is intended to initiate user requests intended for the external Internet network (in this example), or in other words to take into account user requests and initiate the processing associated with them within the device.
  • Layer G is intended for retrieving data streams which are communicated by the external network in response to a request initiated by layer I, or data streams which have been previously retrieved and which have been stored in a cache memory. or buffer.
  • the layer T is provided for the transformation, on request, of the data of the flows previously recovered on the external network or in a buffer memory or cache.
  • the layer S is provided for the transmission to the user terminal of the data retrieved at the level of the layer G, and which it has required, after a possible transformation in the layer T
  • Each elementary processing module stored in memory 4, is intended to apply specific processing to a data stream (“Incoming”), depending on its type, then generating an “outgoing” data stream comprising the processed data accompanied by a request object.
  • the term “request object” is understood here to mean all of the information necessary for the description of the data flow which it accompanies, and the organization of its path through the device (or structure).
  • a request object can include the address of the end user (who requests the data) and a list of processing operations to be carried out (such as applying a filter, changing the protocol, or even removing images from a data page).
  • the elementary processing module On receipt of an incoming flow, the elementary processing module analyzes the request object which accompanies it, in order to determine whether it must process the flow, or not, then it delivers an outgoing flow accompanied by the same request object or 'an "enriched" request object.
  • HTTPPG HTTP data exchange protocol within the G data recovery layer
  • HTTPS HyperText Transfer Protocol
  • CACHES cache through storage functions (for example in association with one and / or the other of the data recovery layers G and data transformation T);
  • LOG a "LOG" module allowing to keep traces of the use of the proxy server in the form of log files whose types of information and storage formats, in particular, are configurable by the user or by a supervisor;
  • an "XSLT” module making it possible to transform, at the level of the data transformation layer T, a data stream recovered in a first format, for example of XML type, into a second format, for example of WML type (adapted to portable type user terminals operating according to the WAP protocol), using a transformation language, for example of the XSLT type;
  • REGEX a "REGEX” module allowing the modification of the content of a stream of recovered and / or transformed data, according to a regular expression list (or expression obeying a particular syntax);
  • a "TAG TRANSLATOR” module to convert a page of recovered data, for example in "HTML” format, into another page of data in the same format, by modifying the tags (or "tags") contained in this page.
  • Such a module allows, for example, to remove one or more images contained in a WEB data page, or to rewrite addresses pointed to by hypertext links, or more generally to delete or add information inside a recovered WEB data page;
  • an "AUTH” module for managing the authentication of the different users of the proxy server 1.
  • a module includes a list of users authorized to use the proxy, possibly according to different criteria, and makes it possible to generate an error page if unauthorized access is requested.
  • Such a module can also make it possible to install a proxy server equipped with the firewall function within a company, so that an employee once returned to his home, or using a laptop outside the private network of the 'company, can have access to internal documents of the company after being authenticated.
  • copies of the elementary processing modules which are stored in the memory 4 and which are necessary for processing a user request are made, then these different elementary modules are associated with the different low-level logic layers ( I, G, T, S) of the structure 6 and finally, each module associated with each layer is configured, using the interface means of modules 5, so that the various associated modules can exchange data with each other with the others in their respective layers.
  • I, G, T, S low-level logic layers
  • each module associated with each layer is configured, using the interface means of modules 5, so that the various associated modules can exchange data with each other with the others in their respective layers.
  • layers I, G and S the transformation layer T n ' being used only in case of need for transformation of the recovered data, at the request of the user.
  • the invention thus makes it possible to constitute, in real time, modular substructures adapted specifically to the needs of the users, that is to say capable of ensuring combinations of functions, reconfigurable and configurable at will, and preferably in time real (or dynamically).
  • the device 2 also includes encapsulation means 7 making it possible to make compatible with the other elementary processing modules, stored in the memory 4, an elementary processing module belonging to another processing device 20, installed in a server remote proxy 10.
  • the encapsulation means 7 are intended to encapsulate, in the computer sense of the term, a basic processing module, external, so that it appears as a basic processing module of the device 2, and can be reused later after being stored in memory 4.
  • the device 2 also preferably includes a buffer memory 8 making it possible to temporarily store, according to chosen criteria, in particular duration, the data (or pages of data) recovered at the level of the layer G and / or at the level of the layer T, and coming from outside network (here, Internet).
  • This buffer memory 8 which is for example of the so-called "dynamic circular” type, is useful, in particular, for performing the cache function. It makes it possible to locally store data or data pages which are regularly requested by the user (s), to save them time.
  • the control module 3 upon receipt of a user request, the control module 3 will first of all check whether the page requested by the user is stored in the buffer memory 8, or whether it is necessary to send a request, via the multilayer structure 6, to the outside network to recover the data requested by the user.
  • the device 2 comprises a graphic interface module 9 which allows a user, or a supervisor of the proxy server 1, to manage in real time (or dynamically) the association of the different elementary processing modules with the different logical layers, as well as their respective configurations, in place of or in addition to the control module 3. Thanks to this graphic interface module 9, the user can obtain on the screen of his terminal T1i, in real time, information on the state of each elementary processing module which has been associated with a logical layer of the multilayer structure 6. The user, or the supervisor, can thus at any time decide to remove and / or add to the multilayer structure which is specifically dedicated to it one or more elementary processing modules.
  • the control means 3 are preferably arranged so as to manage, substantially simultaneously, several user requests which come from several terminals of different users. This is due in particular to the fact that each user request results in the generation of a multilayer structure which is specifically dedicated to it, and in which "copies" of the elementary processing modules stored in the memory 4 are used, with configurations specific to the needs of said users.
  • the control module 3 can also, preferably, associate several times the same elementary treatment module with the same layer, but with different configurations, so that they can provide treatments in series or in parallel, as required.
  • the processing device 2 is not necessarily located in a single proxy server 1. It can in fact be distributed over several remote servers. For example, a first server can be dedicated to the data processing which is carried out in the recovery layer G, while a second server is dedicated only to the data processing which is carried out in the transformation layer T, and that a third server is dedicated to the data processing carried out in the initiation I and transmission S layers.
  • the proxy server can operate in multitasking mode. In this case, it is subdivided into sub-parts each intended to perform a specific task.
  • the different layers of the multilayer structure 6 can be associated with different parts of the server, so as to allow processing in parallel, when necessary.
  • the control module 3 is therefore arranged so as to manage the distribution of tasks within the different parts of the multitasking server, or else within the different servers dedicated to the different tasks.
  • the various elementary processing modules which are associated with the different logical layers to satisfy user requests, exchange data via a common interface, for example of API type (for “Application Program Interface”).
  • the different elementary processing modules which are stored in memory 4, can be the subject of different groupings. In fact, they can be initially grouped into classes which are each associated with one of the layers of the multilayer structure 6. In this case, they are selected within a class associated with a required logical layer, and then configured.
  • the elementary processing modules can also be of the "generic" type. In this case, they must be fully configured so as to be able to provide processing in several logical layers. However, these elementary processing modules can also be grouped into classes each associated with a specific data exchange protocol, such as HTTP. In this case, the elementary processing modules are selected according to their membership of a class designating a particular protocol, then they are associated and they are configured according to the layers with which they must be associated.
  • the multilayer structure 6, the control module 3 and most of the elementary processing modules are software modules (or software) produced in java language.
  • This language is known for its highly dynamic nature allowing to load or unload classes, efficiently, and to connect modules without loss of performance.
  • some modules cannot be effectively written in java language, for example because the management of a network in java language (performed by the "java.net" package) is very inefficient in terms of resources, some elementary processing modules are therefore written in C or C ++ language.
  • the modules are written in C, C ++ or Java, it is particularly advantageous if their programming mode is of the non-blocking type.
  • the module interfacing means 5 operate in the "java management extension (JMX)" mode, well known to those skilled in the art.
  • JMX java management extension
  • the interface (API) used to allow the elementary modules, associated and configured, to exchange data between them is preferably of the "java native interface (JNI)" type. This interface makes it possible to interface either basic modules written in C or C ++ or in java, without this affecting performance.
  • JNI Java native interface
  • the light gray rectangles represent layers of the multilayer structure 6
  • the dark gray rectangles represent elementary processing modules associated with the different layers
  • the dotted arrows represent empty data streams accompanied by a request object
  • the continuous arrows represent non-empty data streams accompanied by a request object
  • the texts inscribed in oval bubbles represent request objects attached to the data stream leaving the elementary processing modules.
  • data flow is meant any type of flow, whether it is full of data or empty of data but accompanied by a request object.
  • data flow is said to be “empty”, while it is said to be “full” in the opposite case.
  • FIG. 3 represents a structure dedicated to a proxy server of the "cache" type.
  • the user transmits, using his user terminal, a request to the proxy server 1.
  • the request is "Pierre wants to see what is at the address www.toto.fr".
  • the control module 3 deduces therefrom that the data exchange protocol used is of the HTTP type. Therefore, it forwards the request to the HTTPI module that has been associated with the request initiation layer I and configured to operate there.
  • the HTTPI module then generates an outgoing data stream in HTTP format and comprising a request object of the "www.toto.fr;Pierre" type. This outgoing data stream is then transmitted to the data recovery layer G, and more precisely to the CACHE module which is associated with it.
  • the CACHE module generates an outgoing data flow to which it appends a request object, here the same as that generated by the HTTPI module, and communicates it to the data transmission layer S, and more precisely to the HTTPS module which is associated with it, so that the data page "www.toto .fr "is transmitted to the user designated by the request object, here," Pierre "", after deleting said request object.
  • the CACHE module generates an outgoing data stream comprising a request object, here the same as that generated by the HTTPI module, which it transmits to the HTTPG module which is like it associated with the retrieval layer G.
  • the HTTPG module retrieves from the web (or Internet network) the data page designated by the request object, and generates an outgoing data stream comprising the data of this retrieved page , accompanied by a request object, which here is always identical to that generated by the HTTPI module.
  • This outgoing stream is transmitted to the data transmission layer S, and more specifically to the HTTPS module associated with it so that the data on the page designated by the request is transmitted to the user "Pierre", after deleting the request object.
  • the configuration of the structure dedicated to the user, or to a group of users, can be carried out beforehand by the supervisor of the proxy server 1. It can then be adapted according to the needs of each user, in real time, either by the user himself, either by the supervisor.
  • this dedicated structure can also be generated on receipt of the user's request, by the control module 3 and / or by the user or the supervisor. In this case, it is the very type of request that triggers the selection of elementary processing modules which must be associated with the different layers necessary for the processing required by the user (for example retrieving data from a WEB page) .
  • the example illustrated in FIG. 4 also corresponds to a proxy server of the cache type, but this time a user authentication function has been added at the level of the data recovery layer. G.
  • the control module 3 Upon receipt of the user's request (here, the user Pierre wants to see the content of the page "www.toto.fr"), the control module 3 transmits it to the request initiation layer I, and more precisely to its HTTPI module (which is specifically adapted to the HTTP data exchange protocol). This module generates an outgoing flow, including the request object “www.toto.fr; Pierre ”, which he transmits to the G data recovery layer, and more precisely to the basic AUTH authentication module. This checks in a list if the user "Pierre” is authorized to recover the data from the page "www.toto.fr".
  • the elementary AUTH authentication module If this is not the case, the elementary AUTH authentication module generates an outgoing data flow comprising a request object of the "ERREUR Pierre" type which it transmits to the data transmission layer S, and more precisely to the module HTTPS associated with it so that the error message is transmitted to the user "Pierre" designated in the object request. On the other hand, if the user "Pierre" is authorized to recover the data designated by his request, the elementary AUTH authentication module generates an outgoing data stream comprising a request object, here identical to that generated by the HTTPI module, and transmits it to the CACHE module. This checks whether the required data page is stored in the cache.
  • the CACHE module generates an outgoing data flow, from the data on the page requested by the user, accompanied by a request object, here the same as that generated by the HTTPI module.
  • This outgoing stream is transmitted to the transmission layer S and more precisely to the HTTPS module which is associated with it, so that the latter transmits the data of the requested page to the user "Pierre" who is designated by the request object, after deleting said request object.
  • the CACHE module If the required data page is not stored in the cache memory, the CACHE module generates an outgoing data stream comprising a request object, here the same as that generated by the HTTPI module, and the transmits to the HTTPG module, so that it retrieves on the WEB, at the address designated by the request object, the data of the requested page.
  • the HTTPG module generates an outgoing data stream accompanied by a request object, here the same as that generated by the HTTPI module, and transmits it to the data transmission layer S, and more precisely to its HTTPS module, so that it transmits the required data page to the user "Pierre", designated by the request object, after deleting said request object.
  • the example illustrated in FIG. 5 also relates to an application of “cache” type with authentication, but supplemented by a selective transformation of the data recovered at the level of the data recovery layer G, that is to say by the CACHE module (when the data required are already stored in the cache memory), or by the HTTPG module (of course when the exchange protocol is of the HTTP type).
  • the control module 3 Upon receipt of the user's request (here, the user Pierre wants to see the content of the page "www.toto.fr"), the control module 3 transmits it to the request initiation layer I, and more precisely to its HTTPI module (which is specifically adapted to the HTTP data exchange protocol). This module generates an outgoing flow, including the request object “www.toto.fr; Pierre ”, which he transmits to the G data recovery layer, and more precisely to the basic AUTH authentication module. This checks in a list if the user "Pierre” is authorized to recover the data from the page "www.toto.fr".
  • the elementary AUTH authentication module If this is not the case, the elementary AUTH authentication module generates an outgoing data flow comprising a request object of the "ERREUR Pierre" type which it transmits to the data transmission layer S, and more precisely to the module HTTPS associated with it so that the error message is transmitted to the user "Pierre” designated in the object request.
  • the basic AUTH authentication module if the user "Pierre” is authorized to recover the data designated by his request, the basic AUTH authentication module generates an outgoing data stream comprising a request object for type "www.toto.fr;Pierre; Selective transformation XX ”(it is in fact the request object generated by the HTTPI module and enriched locally by the AUTH module on the basis of transformation information chosen by the user or the supervisor), and transmits it to the CACHE module. This checks whether the required data page is stored in the cache.
  • the CACHE module generates an outgoing data flow, from the data on the page requested by the user, accompanied by a request object, here the same as that generated by the AUTH module.
  • This outgoing flow is transmitted to the transformation layer T and more precisely to the “selective transformation” module associated with it, so that it performs the processing or treatments specified in the request object, and generates an outgoing flow comprising the data.
  • transforms and a request object here the same as that generated by the AUTH module, intended for the data transmission layer S, and more precisely to its HTTPS module, so that it transmits the required data page to the user "Pierre", designated by the request object, after deleting the request object.
  • the CACHE module If the required data page is not stored in the cache memory, the CACHE module generates an outgoing data stream comprising a request object, here the same as that generated by the AUTH module, and transmits it to the HTTPG module, so that it collects data from the requested page on the WEB, at the address designated by the request object. Once these are retrieved, the HTTPG module generates an outgoing data stream accompanied by a request object, here the same as that generated by the AUTH module. This outgoing flow is transmitted to the transformation layer T and more precisely to the “selective transformation” module associated with it, so that it performs the processing or treatments specified in the request object, and generates an outgoing flow comprising the data.
  • the data exchange protocol can be different from the http protocol, in particular when the data is transmitted in audio and / or video “streaming” mode.
  • several transformation modules identical or different, can be used at the level of the transformation layer T, in parallel or in series, in order to satisfy the needs of the users.
  • the LOG module, or an equivalent can also be associated with the structure to edit logs summarizing, in a specific manner, the data exchanges between the external network and the internal network, or one or more users of the internal network.
  • the invention can also make it possible to produce a proxy generation device (or “proxy factory”), so as i) to allow the production and integration into an installation of one or more dedicated corporate servers, or ii) allow manufacturers or assemblers of servers to generate or adapt said servers to the needs of their customers, without manual manipulation.
  • a proxy generation device or “proxy factory”
  • the various modules and interfacing means which constitute the device according to the invention can be produced in the form of a software module ("software”). However, they can also be produced, at least in part, in the form of electronic circuits ("hardware”), or else in the form of combinations of software modules and electronic circuits.
  • the invention can be used in particular in the field of public or private telecommunications networks and in particular for the broadcasting and reception of data and / or applications to local or remote data terminals connected by networks (wired networks or networks wireless), for example for training courses or meetings whose participants are equipped with data terminals connected to the proxy server by a network, in particular a wireless network.
  • networks wireless networks or networks wireless

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Un dispositif de traitement de données, implantable dans un serveur informatique, comprend i) une structure (6) à couches logiques de bas niveau pour le traitement de données, raccordée à un réseau et à des terminaux d'utilisateurs, et comportant au moins une première couche (I) d'initiation de requêtes d'utilisateur destinées au réseau, une seconde couche (G) de récupération de flux de données transmis par le réseau en réponse à une requête initiée par la première couche (I), une troisième couche (T) de transformation des données des flux récupérés et une quatrième couche (S) pour transmettre aux terminaux d'utilisateurs des données récupérés et éventuellement transformées, ii) des modules élémentaires pour traiter des flux de données, selon leur type, et pour générer des flux de données sortant comportant les données traitées, et iii) des moyens de contrôle (3) pour associer à l'une au moins des couches l'un au moins des modules en fonction d'une requête d'utilisateur, puis configurer chaque module associé à chaque couche de sorte qu'il puisse échanger des flux de données, via des moyens d'interfaçage (5), avec les autres modules associés, ces derniers étant en outre agencés pour adjoindre aux données des flux sortants qu'ils génèrent un objet requête, représentatif du type du flux, de sorte qu'à réception de ce flux un module élémentaire récepteur puisse déterminer s'il doit le traiter.

Description

SERVEUR PERFECTIONNE DE GESTION DE DONNEES ENTRE UN RESEAU ET DES TERMINAUX D'UTILISATEURS, ET DISPOSITIF ET PROCEDE DE TRAITEMENT DE DONNEES ASSOCIES
L'invention concerne le domaine du traitement de données et plus particulièrement celui de la gestion des données échangées entre au moins un réseau externe, public et/ou privé, et des terminaux d'utilisateurs, éventuellement intégrés dans un réseau interne.
Ce type de gestion est généralement assuré par des serveurs informatiques équipés d'un dispositif de traitement de type pare-feu (plus connu sous le mot anglais « firewall »), qui assure la protection des terminaux d'utilisateurs contre les intrusions extérieures, et/ou de type « proxy », qui assure un filtrage et/ou un enregistrement des mouvements d'information et/ou une mémorisation temporaire (ou cache). Lorsque les protocoles d'échange de données utilisés par les réseaux interne et externe sont identiques, le serveur est généralement qualifié de « routeur », tandis que dans le cas contraire il est généralement qualifié de « passerelle ».
L'invention concerne plus particulièrement les serveurs proxys (ou passerelles).
Les serveurs proxys actuels sont dédiés à des services, par exemple Internet, spécifiques. Il existe ainsi, pour les services Internet, des proxys web, des proxys ftp et des proxys telnet, notamment. De par leur conception, ces serveurs proxys ne tolèrent que très peu d'ajout de fonctionnalités (ou « plugin »). Ils ne peuvent donc pas être reconfigurés pour assurer un service différent de celui pour lequel ils ont été conçus.
Les sociétés Inktomi et IBM ont récemment proposé des proxys, respectivement sous les noms « Traffic Server » et « WBI », qui améliorent la situation, dans la mesure où l'un est équipé d'une Interface de type API permettant à un superviseur de communiquer avec lui, et l'autre offre la possibilité d'ajouter des points d'entrée (ou « hooks ») permettant à un superviseur de modifier son comportement. Cependant, ces proxys demeurent associés à un unique protocole (HTTP), non modifiable, et ne permettent pas de contrôler le chemin suivi par le flux de données en leur sein. De ce fait, toute utilisation avancée de ces proxys demeure impossible.
L'invention a donc pour but de résoudre tout ou partie des inconvénients précités.
Elle propose à cet effet un dispositif de traitement de données, destiné à être implanté dans un serveur informatique, et comprenant :
* une structure à couches logiques de bas niveau, pour le traitement de données, destinée à être raccordée à un ou plusieurs réseaux et à un ou plusieurs terminaux d'utilisateur, et comportant au moins une première couche pour initier des requêtes d'utilisateurs destinées à un réseau, une seconde couche pour la récupération des flux de données qui sont transmis par le réseau en réponse à une requête initiée au niveau de la première couche, une troisième couche pour la transformation des données des flux récupérés, et une quatrième couche pour la transmission des données récupérées et éventuellement transformées au terminal de l'utilisateur requérant,
* une multiplicité de modules élémentaires pour appliquer des traitements spécifiques à des flux de données entrant, selon leurs types respectifs, et pour générer des flux de données sortant qui comportent les données traitées,
* des moyens de contrôle pourvus de moyens d'interfaçage de modules (fonctionnant de préférence selon le mode « Java Management extension (JMX) ») et capables d'associer à l'une au moins des couches l'un au moins des modules élémentaires pour satisfaire aux requêtes des utilisateurs, puis de configurer chaque module associé à chaque couche pour qu'il puisse échanger des flux de données, via le module d'interfaçage, avec l'un au moins des modules qui sont associés à sa couche et/ou à la couche suivante,
* les modules configurés et associés à chaque couche étant en outre agencés pour adjoindre aux données du flux sortant qu'ils génèrent un objet requête, qui est représentatif de son type et qui s'enrichit, éventuellement, lors de son passage dans chacune des couches, de sorte qu'à réception de ce flux le module élémentaire récepteur puisse déterminer immédiatement s'il doit le traiter ou bien le transmettre, sans traitement, à un autre module, de la même couche ou de la couche suivante.
Chaque couche de bas niveau est ainsi chargée de gérer certains traitements effectués spécifiquement par le ou les modules élémentaires (ou canoniques) qui lui ont été associés et ces modules constituent des espèces de « boîtes noires » qui échangent des données entre elles via une interface commune, par exemple de type API.
On constitue ainsi un dispositif de traitement hautement modulaire, adaptable à chaque instant aux besoins (requêtes) de ses utilisateurs, et facilement reconfigurable.
Les modules élémentaires peuvent être soit initialement regroupés dans des classes associées chacune à une couche prédéfinie (ils sont ensuite sélectionnés au sein de leur classe et configurés), soit destinés à être intégralement configurables pour assurer des traitements dans plusieurs couches.
Selon une autre caractéristique de l'invention, chaque module élémentaire associé à la quatrième couche est agencé de manière à supprimer l'objet requête qui est attaché à un flux avant que celui-ci ne soit transmis au terminal de l'utilisateur qui avait émis la requête initiale.
Ces modules élémentaires sont de préférence choisis dans un groupe comprenant au moins trois modules de gestion du protocole d'échange de données du réseau, propres à être associés sélectivement aux première, seconde et quatrième couches, un premier module de gestion de mémoire cache pour la récupération de données au niveau de l'une au moins des couches de la structure (et de préférence au niveau de la seconde couche), un second module de gestion de mémoire cache pour le stockage temporaire de données au niveau d'au moins l'une desdites couches de la structure (et de préférence au niveau de la seconde couche et/ou de la troisième couche), un module de sauvegarde pour stocker des données d'information portant sur l'utilisation du dispositif et permettant l'édition de journaux paramétrables, un premier module de transformation de pages de données, dans un format choisi, en d'autres pages de données, dans le même format choisi (il pourra notamment s'agir de modifier des tags, de retirer une ou plusieurs images, de réécrire des adresses pointées par des liens hypertexte, ou plus généralement d'ajouter ou de retirer des données), un second module de transformation destiné à être associé à la troisième couche pour transformer des données récupérées par un module élémentaire associé à la seconde couche et placées dans un premier format (par exemple de type XML) en données dans un second format (par exemple de type WML pour un protocole de type WAP), et un module pour authentifier des opérateurs par confrontation avec une liste mémorisée (de préférence associé à l'une au moins des première et troisième couches). Cette liste n'est pas exhaustive. Elle concerne d'une manière générale tout type de module capable d'effectuer des traitements élémentaires sur des données.
Le dispositif selon l'invention pourra également comporter les caractéristiques suivantes, prises séparément et en combinaison :
* une mémoire tampon (éventuellement de type circulaire dynamique) pour stocker de façon temporaire des données qui sont parvenues au niveau de la seconde couche et/ou de la troisième couche ;
* des moyens de contrôle permettant également de gérer sensiblement simultanément plusieurs (au moins deux) requêtes d'utilisateurs provenant de plusieurs (au moins deux) terminaux d'utilisateurs différents ;
* des moyens de contrôle permettant également d'associer plusieurs fois un même module élémentaire à une même couche, selon des configurations éventuellement différentes, de sorte qu'ils puissent assurer des traitements en série ou en parallèle, identiques ou différents ;
* des moyens de contrôle permettant également de gérer la répartition de tâches de traitement, soit au sein d'un serveur de type multitâches, soit entre plusieurs serveurs (au moins deux). Dans ce dernier cas, l'un des serveurs peut être prévu pour effectuer les traitements associés à une ou plusieurs couches, par exemple la seconde couche (récupération de données), tandis qu'au moins un autre serveur est destiné à effectuer les traitements associés à une ou plusieurs autres couches, par exemple la troisième couche (transformation des données récupérées) ;
* un module d'interfaçage graphique permettant à un utilisateur de gérer, sur l'écran de son terminal d'utilisateur, l'association des différents modules élémentaires aux différentes couches, ainsi que leur configuration. Dans ce cas, le module d'interfaçage graphique peut être également agencé de manière à fournir à un terminal d'utilisateur, qui est raccordé au serveur dans lequel il est implanté, des informations sur l'état de chaque module élémentaire qui a été associé à une couche logique ; *des moyens d'encapsulation pour adapter (ou encapsuler) des modules élémentaires, qui sont issus d'un serveur informatique équipé d'un dispositif de traitement d'un autre type et par conséquent incompatible, de sorte que ce module élémentaire puisse fonctionner dans l'une au moins des couches de la structure.
Le dispositif selon l'invention est de préférence implanté dans un serveur informatique de type « proxy », ou dans un boîtier (tel qu'un équipement informatique), raccordé à un (ou plusieurs) réseau(x) de télécommunications public(s) et/ou privé(s) et à un (ou plusieurs) terminau(x) d'utilisateur, éventuellement en réseau. Tous ses modules, et ses moyens de contrôle, peuvent être réalisés sous la forme de circuits électroniques (« hardware ») et/ou de modules logiciels (« software »). Dans le cas de modules logiciels, certains au moins d'entre eux peuvent être réalisés en langage informatique JAVA, en particulier utilisé en mode de programmation de type non bloquant, ou bien en langage informatique C ou C++.
L'invention concerne en outre un procédé de traitement de données comptables comprenant au moins les étapes suivantes : a) prévoir une structure à couches logiques de bas niveau pour le traitement de données, cette structure comportant au moins une première couche pour initier des requêtes d'utilisateur destinées à un réseau, une seconde couche pour récupérer des flux de données transmis par le réseau en réponse à une requête initiée par la première couche, une troisième couche pour transformer des données de flux récupérés au niveau de la seconde couche, et une quatrième couche pour transmettre les données transformées à l'utilisateur qui avait émis une requête, b) prévoir une multiplicité de modules élémentaires pour appliquer des traitements spécifiques à des flux de données entrant, selon leurs types respectifs, et pour générer des flux de données sortant comportant les données traitées, c) associer à l'une au moins des couches l'un au moins des modules élémentaires pour satisfaire à la requête de l'utilisateur, puis configurer chaque module associé à chaque couche de sorte qu'il puisse échanger des flux de données avec l'un au moins des modules qui sont associés à sa couche et/ou à la couche suivante, et d) adjoindre au flux de données qui sort de chaque module élémentaire, configuré et associé à une couche, un objet requête, représentatif du type dudit flux sortant et destiné, éventuellement, à s'enrichir lors de son passage dans chacune des couches, de sorte qu'à réception de ce flux le module élémentaire récepteur puisse déterminer immédiatement s'il doit le traiter ou bien le transmettre, sans traitement, à un autre module, de la même couche ou de la couche suivante.
D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée ci-après, et des dessins annexés, sur lesquels :
- la figure 1 illustre de façon très schématique une installation équipée d'un serveur proxy selon l'invention,
- la figure 2 est un diagramme bloc illustrant de façon très schématique une partie d'un dispositif de traitement selon l'invention implanté dans un serveur proxy, - la figure 3 est un schéma illustrant un procédé d'association et de configuration de modules selon l'invention, adapté à une requête d'utilisateur, dans une application de type « proxy cache »,
- la figure 4 est un schéma illustrant un procédé d'association et de configuration de modules selon l'invention, adapté à une requête d'utilisateur, dans une application de type « proxy cache » avec authentification de l'utilisateur, et
- la figure 5 est un schéma illustrant un procédé d'association et de configuration de modules selon l'invention, adapté à une requête d'utilisateur, dans une application de type « proxy cache » avec authentification de l'utilisateur et transformation des données récupérées.
Les dessins annexés sont, pour l'essentiel, de caractère certain. En conséquence, ils pourront non seulement servir à compléter l'invention, mais aussi contribuer à sa définition, le cas échéant.
Dans la description qui suit, il sera fait référence à une installation de traitement de données, du type de celle illustrée sur la figure 1. Cette installation comprend notamment un serveur proxy 1 , dans lequel est implanté un dispositif de traitement 2 selon l'invention, qui sera décrit plus loin en référence à la figure 2, raccordé, d'une part, à un réseau public, de type Internet et, d'autre part, à un réseau privé de type Intranet, via un serveur SRI1 raccordé à une multiplicité de terminaux d'utilisateurs T1i (ici i = 1 à N).
Bien entendu, le dispositif pourrait être implanté dans un boîtier externe, de type équipement auxiliaire, raccordé au serveur SRM, celui-ci étant alors directement raccordé au réseau externe Internet.
Comme cela est bien connu de l'homme de l'art, de nombreux sites Web SWj (ici j = 1 à 3) sont raccordés au réseau public Internet. Un terminal d'utilisateurs peut donc, en émettant une requête d'accès à une page de données stockées dans un site Web SWj, accéder à ces données, ou en d'autres termes les récupérer, via le réseau Internet, le serveur proxy 1 et le serveur SRI1. Le serveur proxy 1 ou le serveur SRM peut éventuellement assurer la fonction de coupe-feu (ou « firewall »).
D'autres serveurs de réseaux privés (ici SRI2) peuvent être également raccordés au réseau public Internet, éventuellement via un autre serveur proxy 10 équipé soit d'un dispositif de traitement selon l'invention, soit d'un dispositif de traitement de données standard 20.
Comme indiqué dans l'introduction, un serveur proxy, ou passerelle, est un dispositif informatique qui sert d'interface entre un réseau externe, tel qu'Internet, qui utilise un premier protocole d'échange de données, et un ou plusieurs terminaux d'utilisateurs, éventuellement raccordés à un réseau privé qui utilise un second protocole d'échange de données. Lorsque le protocole d'échange de données utilisé dans le réseau externe est identique à celui utilisé dans le réseau privé, le serveur informatique est qualifié de routeur.
Comme cela est bien connu de l'homme du métier, un serveur proxy assure généralement l'une au moins des trois fonctions principales suivantes :
- la mémorisation temporaire de données, plus connue sous le terme "cache", qui consiste à conserver localement, dans une mémoire adaptée à cet effet, les pages qui sont les plus couramment visitées par les utilisateurs, de manière à en accélérer le chargement sur leurs terminaux ;
- l'enregistrement des informations qui sont échangées entre les terminaux d'utilisateurs et le réseau externe. Généralement, il s'agit de sauvegarder dans une mémoire, adaptée à cet effet, l'adresse de l'utilisateur, les adresses (par exemple URL) des pages consultées sur les différents sites, la date et l'heure de la consultation ;
- le filtrage des données qui le traversent, de sorte que seules les données qui correspondent aux critères prédéfinis (et paramétrables) de filtrage soient transmises à l'utilisateur requérant. Tout type de filtrage peut être envisagé. Il peut être généralisé à l'ensemble d'un réseau, ou à des sous-parties d'un réseau, ou encore adapté à chaque utilisateur. Dans ce dernier cas, le filtrage porte également sur l'authentification de l'utilisateur.
Parfois, le serveur proxy peut également assurer la fonction de coupe-feu, de manière à protéger les terminaux d'utilisateurs, ou le réseau privé, des agressions provenant du réseau extérieur. Dans l'exemple illustré sur la figure 1 , le serveur proxy sert d'interface entre le réseau Internet et un réseau privé comportant un serveur interne SRI1. Mais, le serveur proxy peut être implanté en de nombreux autres endroits, comme par exemple chez un prestataire de services, ou chez un câble-opérateur.
On se réfère maintenant à la figure 2 pour décrire en détail un dispositif de traitement selon l'invention.
Ce dispositif comporte, tout d'abord, un module de contrôle 3, une multiplicité de modules élémentaires de traitement, de préférence stockés dans une mémoire 4, des moyens 5 d'interfaçage des modules élémentaires de traitement, et une structure 6 à couches logiques de bas niveau.
Cette structure multicouches 6 comporte au moins quatre couches I, G, T et S destinées à assurer des traitements de données spécifiques. La couche I est prévue pour initier des requêtes d'utilisateurs destinées au réseau externe Internet (dans cet exemple), ou en d'autres termes pour prendre en compte les requêtes des utilisateurs et initier les traitements qui leurs sont associés au sein du dispositif. La couche G est prévue pour la récupération des flux de données qui sont communiqués par le réseau externe en réponse à une requête initiée par la couche I, ou bien des flux de données qui ont été précédemment récupérés et qui ont été stockés dans une mémoire cache ou tampon. La couche T est prévue pour la transformation, sur requête, des données des flux précédemment récupérés sur le réseau externe ou dans une mémoire tampon ou cache. La couche S est prévue pour la transmission au terminal de l'utilisateur des données récupérées au niveau de la couche G, et qu'il a requises, après une éventuelle transformation dans la couche T.
Chaque module élémentaire de traitement, stocké dans la mémoire 4, est destiné à appliquer un traitement spécifique à un flux de données (« entrant »), en fonction de son type, puis à générer un flux de données « sortant » comportant les données traitées accompagnées d'un objet requête. On entend ici par « objet requête » l'ensemble des informations nécessaires à la description du flux de données qu'il accompagne, et l'organisation de son cheminement au travers du dispositif (ou de la structure). Par exemple, un objet requête peut comporter l'adresse de l'utilisateur final (qui requiert les données) et une liste de traitements à effectuer (comme par exemple appliquer un filtre, ou changer le protocole, ou encore retirer les images d'une page de données). A réception d'un flux entrant, le module élémentaire de traitement analyse l'objet requête qui l'accompagne, de manière à déterminer si il doit traiter le flux, ou non, puis il délivre un flux sortant accompagné du même objet requête ou d'un objet requête « enrichi ».
Un certain nombre de modules élémentaires de traitement sont indiqués ci-après, seulement à titre d'exemples non limitatifs :
- un premier module "HTTPI", responsable de la gestion du protocole d'échange de données HTTP au sein de la couche d'initiation de requête I ;
- un module "HTTPG", responsable de la gestion du protocole d'échange de données HTTP au sein de la couche de récupération de données G ;
- un module "HTTPS", responsable de la gestion du protocole d'échange de données HTTP au sein de la couche de transmission de données S ;
- un module "CACHEG", permettant de gérer un cache à travers des fonctions de récupération (par exemple en association avec la couche de récupération de données G) ;
- un module "CACHES", destiné à gérer un cache à travers des fonctions de stockage (par exemple en association avec l'une et/ou l'autre des couches de récupération de données G et de transformation de données T) ; - un module "LOG" permettant de conserver des traces de l'utilisation du serveur proxy sous la forme de fichiers journaux dont les types d'informations et les formats de stockage, notamment, sont configurables par l'utilisateur ou par un superviseur ;
- un module "XSLT" permettant de transformer, au niveau de la couche de transformation de données T, un flux de données récupéré dans un premier format, par exemple de type XML, en un second format, par exemple de type WML (adapté aux terminaux d'utilisateur de type portable fonctionnant selon le protocole WAP), grâce à un langage de transformation, par exemple de type XSLT ;
- un module "REGEX" permettant la modification du contenu d'un flux de données récupérées et/ou transformées, selon une liste d'expression régulière (ou expression obéissant à une syntaxe particulière) ;
- un module "TAG TRANSLATOR" permettant de convertir une page de données récupérée, par exemple dans le format "HTML", en une autre page de données dans le même format, grâce à une modification des balises (ou « tags ») contenues dans cette page. Un tel module permet, par exemple, de retirer une ou plusieurs images contenues dans une page de données WEB, ou de réécrire des adresses pointées par des liens hypertextes, ou plus généralement de supprimer ou d'ajouter des informations à l'intérieur d'une page de données WEB récupérée ;
- un module "AUTH" permettant de gérer l'authentification des différents utilisateurs du serveur proxy 1. Un tel module comporte une liste d'utilisateurs autorisés à utiliser le proxy, éventuellement selon des critères différents, et permet de générer une page d'erreur si un accès non autorisé est demandé. Un tel module peut permettre également d'installer un serveur proxy équipé de la fonction coupe-feu au sein d'une entreprise, de sorte qu'un employé une fois rentré à son domicile, ou utilisant un portable en dehors du réseau privé de l'entreprise, puisse avoir accès aux documents internes de l'entreprise après avoir été authentifié.
Bien entendu, d'autres modules élémentaires de traitement peuvent être envisagés, comme notamment la gestion de différents protocoles.
Selon l'invention, on effectue des copies des modules élémentaires de traitement qui sont stockés dans la mémoire 4 et qui sont nécessaires au traitement d'une requête d'utilisateur, puis on associe ces différents modules élémentaires aux différentes couches logiques de bas niveau (I, G, T, S) de la structure 6 et enfin on configure, à l'aide des moyens d'interfaçage de modules 5, chaque module associé à chaque couche, de sorte que les différents modules associés puissent échanger des données les uns avec les autres dans leurs couches respectives. Bien entendu, comme on le verra plus loin, il n'est pas toujours nécessaire d'utiliser les quatre couches de bas niveau de la structure 6. Généralement, on utilise les couches I, G et S, la couche de transformation T n'étant utilisée qu'en cas de besoin de transformation des données récupérées, sur requête de l'utilisateur.
L'invention permet ainsi de constituer, en temps réel, des sous- structures modulaires adaptées spécifiquement aux besoins des utilisateurs, c'est-à-dire propres à assurer des combinaisons de fonctions, reconfigurables et paramétrables à volonté, et de préférence en temps réel (ou dynamiquement).
De préférence, le dispositif 2 comporte également des moyens d'encapsulation 7 permettant de rendre compatible avec les autres modules élémentaires de traitement, stockés dans la mémoire 4, un module élémentaire de traitement appartenant à un autre dispositif de traitement 20, implanté dans un serveur proxy distant 10. En fait, les moyens d'encapsulation 7 sont destinés à encapsuler, dans le sens informatique du terme, un module élémentaire de traitement, externe, de sorte qu'il apparaisse comme un module élémentaire de traitement du dispositif 2, et puisse être réutilisé ultérieurement après avoir été stocké dans la mémoire 4.
Le dispositif 2 comporte également, de préférence, une mémoire tampon 8 permettant de stocker temporairement, selon des critères choisis, notamment de durée, les données (ou pages de données) récupérées au niveau de la couche G et/ou au niveau de la couche T, et provenant du réseau extérieur (ici, Internet). Cette mémoire tampon 8, qui est par exemple du type dit "circulaire dynamique", est utile, notamment, pour réaliser la fonction cache. Elle permet en effet de stocker localement des données ou pages de données qui sont régulièrement demandées par le ou les utilisateurs, pour leur faire gagner du temps. En d'autres termes, à réception d'une requête d'utilisateur, le module de contrôle 3 va tout d'abord vérifier si la page requise par l'utilisateur est stockée dans la mémoire tampon 8, ou bien s'il faut émettre une requête, via la structure multicouches 6, à destination du réseau extérieur pour récupérer les données demandées par l'utilisateur.
Egalement de préférence, le dispositif 2 comporte un module d'interfaçage graphique 9 qui permet à un utilisateur, ou à un superviseur du serveur proxy 1 , de gérer en temps réel (ou dynamiquement) l'association des différents modules élémentaires de traitement aux différentes couches logiques, ainsi que leurs configurations respectives, à la place du module de contrôle 3 ou en complément de celui-ci. Grâce à ce module d'interfaçage graphique 9, l'utilisateur peut obtenir sur l'écran de son terminal T1i, en temps réel, des informations sur l'état de chaque module élémentaire de traitement qui a été associé à une couche logique de la structure multicouches 6. L'utilisateur, ou le superviseur, peut ainsi à tout moment décider de retirer et/ou d'ajouter à la structure multicouches qui lui est spécifiquement dédiée un ou plusieurs modules élémentaires de traitement.
Les moyens de contrôle 3 sont préférentiellement agencés de manière à gérer, sensiblement simultanément, plusieurs requêtes d'utilisateurs qui proviennent de plusieurs terminaux d'utilisateurs différents. Cela est dû notamment au fait que chaque requête d'utilisateur aboutit à la génération d'une structure multicouches qui lui est spécifiquement dédiée, et dans laquelle sont utilisées des "copies" des modules élémentaires de traitement stockés dans la mémoire 4, avec des configurations spécifiques aux besoins desdits utilisateurs.
Le module de contrôle 3 peut également, de préférence, associer plusieurs fois un même module élémentaire de traitement à une même couche, mais avec des configurations différentes, afin qu'ils puissent assurer des traitements en série ou en parallèle, selon les besoins.
Le dispositif de traitement 2 selon l'invention n'est pas nécessairement localisé dans un unique serveur proxy 1. Il peut en effet être réparti sur plusieurs serveurs distants. Par exemple, un premier serveur peut être dédié aux traitements de données qui sont effectués dans la couche de récupération G, tandis qu'un second serveur n'est dédié qu'aux traitements de données qui sont effectués dans la couche de transformation T, et qu'un troisième serveur est dédié aux traitements de données effectués dans les couches d'initiation I et de transmission S.
En variante, le serveur proxy peut fonctionner en mode multitâches. Dans ce cas, il est subdivisé en sous-parties destinées chacune à assurer une tâche spécifique. Par exemple, les différentes couches de la structure multicouches 6 peuvent être associées à différentes parties du serveur, de manière à permettre des traitements en parallèle, lorsque cela s'avère nécessaire. Dans cette situation, le module de contrôle 3 est donc agencé de manière à gérer la répartition des tâches au sein des différentes parties du serveur multitâches, ou bien au sein des différents serveurs dédiés aux différentes tâches.
Les différents modules élémentaires de traitement qui sont associés aux différentes couches logiques pour satisfaire les requêtes des utilisateurs, échangent des données via une interface commune, par exemple de type API (pour « Application Program Interface »).
Les différents modules élémentaires de traitement, qui sont stockés dans la mémoire 4, peuvent faire l'objet de différents regroupements. En effet, ils peuvent être initialement regroupés dans des classes qui sont associées chacune à l'une des couches de la structure multicouches 6. Dans ce cas, ils sont sélectionnés au sein d'une classe associée à une couche logique requise, puis configurés. Les modules élémentaires de traitement peuvent être également de type "générique". Dans ce cas, ils doivent être intégralement configurés de manière à pouvoir assurer des traitements dans plusieurs couches logiques. Mais, ces modules élémentaires de traitement peuvent être également regroupés dans des classes associées chacune à un protocole d'échange de données spécifique, comme par exemple HTTP. Dans ce cas, on sélectionne les modules élémentaires de traitement en fonction de leur appartenance à une classe désignant un protocole particulier, puis on les associe et on les configure en fonction des couches auxquelles ils doivent être associés.
Préférentiellement, la structure multicouches 6, le module de contrôle 3 et la plupart des modules élémentaires de traitement (au moins) sont des modules logiciels (ou software) réalisés en langage java. Ce langage est connu pour son caractère hautement dynamique permettant de charger ou décharger des classes, efficacement, et de relier des modules sans perte de performance. Bien entendu, certains modules ne pouvant pas être efficacement écrits en langage java, par exemple du fait que la gestion d'un réseau en langage java (réalisée par le package "java.net") est très peu efficace en terme de ressources, certains modules élémentaires de traitement sont donc rédigés en langage C ou C++. Mais, que les modules soient rédigés en C, C++ ou en java, il est particulièrement avantageux que leur mode de programmation soit de type non bloquant.
Egalement de préférence, les moyens d'interfaçage de modules 5 fonctionnent selon le mode "java management extension (JMX)", bien connu de l'homme du métier. Ce type d'interface JMX permet d'effectuer une administration "à la volée" des modules élémentaires de traitement, et notamment leur chargement, leur déchargement et leur configuration.
Par ailleurs, l'interface (API) utilisée pour permettre aux modules élémentaires, associés et configurés, d'échanger des données entre eux, est de préférence du type "java native interface (JNI)". Cette interface permet en effet d'interfacer indifféremment des modules élémentaires écrits en C ou C++ ou en java, sans que cela ne nuise aux performances.
On se réfère maintenant aux figures 3 à 5 pour décrire différents exemples de procédé d'association et de configuration de modules, selon l'invention. Dans ces figures, les rectangles en gris clair représentent des couches de la structure multicouches 6, les rectangles en gris foncé représentent des modules élémentaires de traitement associés aux différentes couches, les flèches en pointillés représentent des flux de données vides accompagnés d'un objet requête, les flèches en continu représentent des flux de données non vides accompagnés d'un objet requête, et les textes inscrits dans des bulles ovales représentent des objets requêtes attachés au flux de données sortant des modules élémentaires de traitement.
Il est important de noter que dans cette invention on entend par « flux de données » tout type de flux, qu'il soit plein de données ou vide de données mais accompagné d'un objet requête. En d'autres termes, tant que l'on n'a pas récupéré des données, dans une mémoire cache ou sur le réseau extérieur, le flux de données est dit « vide », tandis qu'il est dit « plein » dans le cas contraire.
L'exemple illustré sur la figure 3 représente une structure dédiée à un serveur proxy de type "cache".
L'utilisateur transmet, à l'aide de son terminal utilisateur, une requête au serveur proxy 1. Ici, la requête est "Pierre veut voir ce qui se trouve à l'adresse www.toto.fr". A réception de cette requête d'utilisateur, le module de contrôle 3 en déduit que le protocole d'échange de données utilisé est du type HTTP. Par conséquent, il transmet la requête au module HTTPI qui a été associé à la couche d'initiation de requête I et configuré pour y fonctionner. Le module HTTPI génère alors un flux de données sortant au format HTTP et comportant un objet requête de type "www.toto.fr ; Pierre". Ce flux de données sortant est ensuite transmis à la couche de récupération de données G, et plus précisément au module CACHE qui lui est associé. Il s'agit en fait d'examiner le contenu de la mémoire cache pour déterminer si la page de données, demandée par l'utilisateur, s'y trouve déjà stockée. Si tel est le cas, le module CACHE génère un flux de données sortant auquel il adjoint un objet requête, ici le même que celui généré par le module HTTPI, et le communique à la couche de transmission de données S, et plus précisément au module HTTPS qui lui est associé, de sorte que la page de données "www.toto.fr" soit transmise à l'utilisateur désigné par l'objet requête, ici, "Pierre"", après suppression dudit objet requête.
En revanche, si la page de données n'est pas stockée dans la mémoire cache, le module CACHE génère un flux de données sortant comportant un objet requête, ici le même que celui généré par le module HTTPI, qu'il transmet au module HTTPG qui est comme lui associé à la couche de récupération G. Le module HTTPG récupère alors sur le web (ou réseau Internet) la page de données désignée par l'objet requête, et génère un flux de données sortant comportant les données de cette page récupérée, accompagnées par un objet requête, qui est ici toujours identique à celui généré par le module HTTPI. Ce flux sortant est transmis à la couche de transmission de données S, et plus précisément au module HTTPS qui lui est associé de sorte que les données de la page désignée par la requête soient transmises à l'utilisateur "Pierre", après suppression de l'objet requête.
La configuration de la structure dédiée à l'utilisateur, ou à un groupe d'utilisateurs, peut être préalablement effectuée par le superviseur du serveur proxy 1. Elle peut ensuite être adaptée en fonction des besoins de chaque utilisateur, en temps réel, soit par l'utilisateur lui-même, soit par le superviseur. Mais, cette structure dédiée peut également être générée à réception de la requête de l'utilisateur, par le module de contrôle 3 et/ou par l'utilisateur ou le superviseur. Dans ce cas, c'est le type même de la requête qui déclenche la sélection des modules élémentaires de traitement qui doivent être associés aux différentes couches nécessaires au traitement requis par l'utilisateur (par exemple la récupération des données d'une page WEB).
L'exemple illustré sur la figure 4 correspond également à un serveur proxy de type cache, mais cette fois-ci une fonction d'authentification de l'utilisateur a été ajoutée au niveau de la couche de récupération de données G.
A réception de la requête de l'utilisateur (ici, l'utilisateur Pierre veut voir le contenu de la page "www.toto.fr"), le module de contrôle 3 la transmet à la couche d'initiation de requête I, et plus précisément à son module HTTPI (qui est spécifiquement adapté au protocole d'échange de données HTTP). Ce module génère un flux sortant, comprenant l'objet requête « www.toto.fr ; Pierre », qu'il transmet à la couche de récupération de données G, et plus précisément au module élémentaire d'authentification AUTH. Celui-ci vérifie dans une liste si l'utilisateur "Pierre" est autorisé à récupérer les données de la page « www.toto.fr ».
Si ce n'est pas le cas, le module élémentaire d'authentification AUTH génère un flux de données sortant comportant un objet requête de type "ERREUR Pierre" qu'il transmet à la couche de transmission de données S, et plus précisément au module HTTPS qui lui est associé de sorte que le message d'erreur soit transmis à l'utilisateur "Pierre" désigné dans la requête objet. En revanche, si l'utilisateur "Pierre" est autorisé à récupérer les données désignées par sa requête, le module élémentaire d'authentification AUTH génère un flux de données sortant comportant un objet requête, ici identique à celui généré par le module HTTPI, et le transmet au module CACHE. Celui-ci vérifie si la page de données requise est stockée dans la mémoire cache.
Si tel est le cas, le module CACHE génère un flux de données sortant, à partir des données de la page requise par l'utilisateur, accompagné d'un objet requête, ici le même que celui généré par le module HTTPI. Ce flux sortant est transmis à la couche de transmission S et plus précisément au module HTTPS qui lui est associé, de sorte que ce dernier transmette les données de la page requise à l'utilisateur "Pierre" qui est désigné par l'objet requête, après suppression dudit objet requête.
Si la page de données requise n'est pas stockée dans la mémoire cache, le module CACHE génère un flux de données sortant comportant un objet requête, ici le même que celui généré par le module HTTPI, et le transmet au module HTTPG, de sorte qu'il récupère sur le WEB, à l'adresse désignée par l'objet requête, les données de la page requise. Une fois celles- ci récupérées, le module HTTPG génère un flux de données sortant accompagné d'un objet requête, ici le même que celui généré par le module HTTPI, et le transmet à la couche de transmission de données S, et plus précisément à son module HTTPS, de sorte qu'il transmette la page de données requise à l'utilisateur "Pierre", désigné par l'objet requête, après suppression dudit objet requête.
L'exemple illustré sur la figure 5 concerne également une application de type "cache" avec authentification, mais complétée par une transformation sélective des données récupérées au niveau de la couche de récupération de données G, soit par le module CACHE (lorsque les données requises sont déjà stockées dans la mémoire cache), soit par le module HTTPG (bien entendu lorsque le protocole d'échange est de type HTTP).
A réception de la requête de l'utilisateur (ici, l'utilisateur Pierre veut voir le contenu de la page "www.toto.fr"), le module de contrôle 3 la transmet à la couche d'initiation de requête I, et plus précisément à son module HTTPI (qui est spécifiquement adapté au protocole d'échange de données HTTP). Ce module génère un flux sortant, comprenant l'objet requête « www.toto.fr ; Pierre », qu'il transmet à la couche de récupération de données G, et plus précisément au module élémentaire d'authentification AUTH. Celui-ci vérifie dans une liste si l'utilisateur "Pierre" est autorisé à récupérer les données de la page « www.toto.fr ».
Si ce n'est pas le cas, le module élémentaire d'authentification AUTH génère un flux de données sortant comportant un objet requête de type "ERREUR Pierre" qu'il transmet à la couche de transmission de données S, et plus précisément au module HTTPS qui lui est associé de sorte que le message d'erreur soit transmis à l'utilisateur "Pierre" désigné dans la requête objet. En revanche, si l'utilisateur "Pierre" est autorisé à récupérer les données désignées par sa requête, le module élémentaire d'authentification AUTH génère un flux de données sortant comportant un objet requête de type « www.toto.fr ; Pierre; Transformation sélective XX » (c'est en fait l'objet requête généré par le module HTTPI et enrichi localement par le module AUTH sur la base des informations de transformation choisies par l'utilisateur ou le superviseur), et le transmet au module CACHE. Celui-ci vérifie si la page de données requise est stockée dans la mémoire cache.
Si tel est le cas, le module CACHE génère un flux de données sortant, à partir des données de la page requise par l'utilisateur, accompagné d'un objet requête, ici le même que celui généré par le module AUTH. Ce flux sortant est transmis à la couche de transformation T et plus précisément au module « Transformation sélective » qui lui est associé, de sorte qu'il effectue le ou les traitements spécifiés dans l'objet requête, et génère un flux sortant comportant les données transformées et un objet requête, ici le même que celui généré par le module AUTH, à destination de la couche de transmission de données S, et plus précisément à son module HTTPS, de sorte qu'il transmette la page de données requise à l'utilisateur "Pierre", désigné par l'objet requête, après suppression dudit objet requête.
Si la page de données requise n'est pas stockée dans la mémoire cache, le module CACHE génère un flux de données sortant comportant un objet requête, ici le même que celui généré par le module AUTH, et le transmet au module HTTPG, de sorte qu'il récupère sur le WEB, à l'adresse désignée par l'objet requête, les données de la page requise. Une fois celles- ci récupérées, le module HTTPG génère un flux de données sortant accompagné d'un objet requête, ici le même que celui généré par le module AUTH. Ce flux sortant est transmis à la couche de transformation T et plus précisément au module « Transformation sélective » qui lui est associé, de sorte qu'il effectue le ou les traitements spécifiés dans l'objet requête, et génère un flux sortant comportant les données transformées et un objet requête, ici le même que celui généré par le module AUTH, à destination de la couche de transmission de données S, et plus précisément à son module HTTPS, de sorte qu'il transmette la page de données requise à l'utilisateur "Pierre", désigné par l'objet requête, après suppression dudit objet requête. Les trois exemples qui viennent d'être décrits, en référence aux figures 3 à 5, ne sont en aucune façon limitatifs. Par exemple, le protocole d'échange de données peut être différent du protocole http, notamment lorsque les données sont transmises en mode « streaming » audio et/ou vidéo. De même, plusieurs modules de transformation, identiques ou différents, peuvent être utilisés au niveau de la couche de transformation T, en parallèle ou en série, afin de satisfaire aux besoins des utilisateurs. On peut notamment effectuer une conversion de format en associant le module XSLT, ou un équivalent, à la couche de transformation T, ou une modification du contenu d'un flux de données récupérées et/ou transformées, selon une liste d'expression régulière, en associant le module REGEX, ou un équivalent, à la couche de transformation T; ou encore une conversion de page de données récupérée, par exemple dans le format "HTML", en une autre page de données dans le même format, grâce à une modification des tags dans la page régulière, en associant le module TAG TRANSLATOR, ou un équivalent, à la couche de transformation T. Mais, on peut également effectuer un filtrage des données récupérées sur le web (ou sur tout autre réseau), en associant un module de filtrage à la couche de transformation T (par exemple). On peut également associer à la structure le module LOG, ou un équivalent, pour éditer des journaux récapitulant, de façon spécifique, les échanges de données entre le réseau externe et le réseau interne, ou un ou plusieurs utilisateurs du réseau interne.
D'autres modules élémentaires peuvent également être envisagés comme par exemple un module d'optimisation de la bande passante, un module de développement d'outils de transformation destinés à assurer le suivi des utilisateurs.
Mais l'invention peut également permettre de réaliser un dispositif de génération de proxys (ou « proxy factory »), de manière i) à permettre la production et l'intégration dans une installation d'un ou plusieurs serveurs d'entreprises, dédiés, ou ii) à permettre aux fabricants ou assembleurs de serveurs de générer ou d'adapter lesdits serveurs aux besoins de leurs clients, sans manipulation manuelle.
Comme indiqué précédemment, les différents modules et moyens d'interfaçage qui constituent le dispositif selon l'invention peuvent être réalisés sous la forme de module logiciel ("software"). Mais ils peuvent être également réalisés, au moins en partie, sous la forme de circuits électroniques ("hardware"), ou encore sous la forme de combinaisons de modules logiciels et de circuits électroniques.
L'invention est utilisable notamment dans le domaine des réseaux de télécommunications publics ou privés et en particulier pour la diffusion et la réception de données et/ou d'applications vers des terminaux de données locaux ou distants connectés par des réseaux (réseaux filaires ou réseaux sans fil), par exemple pour des formations ou des réunions dont les participants sont équipés de terminaux de données connectés au serveur proxy par un réseau, notamment un réseau sans fil.
L'invention ne se limite pas aux modes de réalisation de dispositif, d'installation et de procédé décrits ci-avant, seulement à titre d'exemple, mais elle englobe toutes les variantes que pourra envisager l'homme de l'art dans le cadre des revendications ci-après.

Claims

REVENDICATIONS
1. Dispositif de traitement de données (2), implantable dans un serveur informatique (1 ), caractérisé en ce qu'il comprend :
* une structure (6) à couches logiques de bas niveau pour le traitement de données, propre à être raccordée à au moins un réseau et à au moins un terminal d'utilisateur (T1i), et comportant au moins une première couche (I) permettant d'initier des requêtes d'utilisateur à destination dudit réseau, une seconde couche (G) destinée à récupérer des flux de données transmis par ledit réseau en réponse à une requête initiée par la première couche (I), une troisième couche (T) destinée à transformer des données de flux récupérés, et une quatrième couche (S) destinée à transmettre au terminal de l'utilisateur lesdites données récupérées et éventuellement transformées,
* une multiplicité de modules élémentaires agencés pour appliquer des traitements spécifiques à des flux de données entrant, selon leur type, et pour générer des flux de données sortant comportant lesdites données traitées,
* des moyens de contrôle (3) comportant des moyens d'interfaçage de modules (5) et agencés pour associer à l'une au moins des couches l'un au moins des modules en fonction d'une requête d'utilisateur, puis configurer chaque module associé à chaque couche de sorte qu'il puisse échanger des flux de données, via lesdits moyens d'interfaçage (5), avec au moins un module de la couche qui suit la sienne et/ou au moins un autre module de sa couche,
* lesdits modules configurés et associés à chaque couche étant en outre agencés pour adjoindre aux données du flux sortant qu'ils génèrent un objet requête, représentatif du type dudit flux sortant et s'enrichissant de couche en couche, de sorte qu'à réception de ce flux un module élémentaire récepteur puisse déterminer s'il doit traiter ledit flux ou le transmettre sans traitement à un autre module.
2. Dispositif selon la revendication 1 , caractérisé en ce que chaque module élémentaire associé à la quatrième couche (S) est agencé pour supprimer l'objet requête attaché à un flux avant qu'il ne soit transmis à un terminal d'utilisateur (T1i).
3. Dispositif selon l'une des revendications 1 et 2, caractérisé en ce que lesdits modules élémentaires sont choisis dans un groupe comprenant au moins un premier (HTTPI), un second (HTTPG) et un troisième (HTTPS) modules de gestion du protocole d'échange de données du réseau, propres à être associés sélectivement aux première (I), seconde (G) et quatrième (S) couches, respectivement, un premier module (CACHEG) de gestion de mémoire cache pour la récupération de données au niveau de l'une desdites couches de la structure, un second module (CACHES) de gestion de mémoire cache pour le stockage temporaire de données au niveau de l'une desdites couches de la structure, un module de sauvegarde (LOG) destiné à stocker des données d'information portant sur l'utilisation du dispositif et permettant l'édition de journaux paramétrables, un premier module (TAG TRANSLATOR) de transformation d'une page de données, dans un format choisi, en une autre page de données, dans ledit format choisi, un second module de transformation (XSLT) propre à être associé à la troisième couche (T) et agencé pour transformer des données récupérées par un module élémentaire associé à la seconde couche (G) et placées dans un premier format en données dans un second format, et un module d'authentification (AUTH) agencé pour authentifier des opérateurs par confrontation à une liste mémorisée.
4. Dispositif selon la revendication 3, caractérisé en ce que ledit premier module de gestion de mémoire cache (CACHEG) est destiné à récupérer des données au niveau de la seconde couche (G).
5. Dispositif selon l'une des revendications 3 et 4, caractérisé en ce que ledit second module de gestion de mémoire cache (CACHES) est destiné à stocker des données au niveau de l'une au moins des seconde (G) et troisième (T) couches.
6. Dispositif selon l'une des revendications 3 à 5, caractérisé en ce que ledit module d'authentification (AUTH) est destiné à être associé à l'une au moins des première (I) et troisième (T) couches.
7. Dispositif selon l'une des revendications 1 à 6, caractérisé en ce qu'il comprend un module d'interfaçage graphique (9) agencé pour permettre à un utilisateur de gérer en temps réel, sur un écran de son terminal d'utilisateur (T1i), ladite association des modules élémentaires aux différentes couches et leur configuration.
8. Dispositif selon la revendication 7, caractérise en ce que ledit module d'interfaçage graphique (9) est agencé pour fournir en temps réel à un terminal d'utilisateur (T1i) raccordé audit serveur (1) des informations sur l'état d'au moins chaque module élémentaire associé à une couche logique.
9. Dispositif selon l'une des revendications 1 à 8, caractérisé en ce qu'il comprend une mémoire tampon (8) agencée pour stocker de façon temporaire des données parvenues au niveau de la seconde couche (G) et/ou de la troisième couche (T).
10. Dispositif selon la revendication 9, caractérisé en ce que ladite mémoire tampon (8) est de type circulaire dynamique.
11. Dispositif selon l'une des revendications 1 à 10, caractérisé en ce que lesdits moyens de contrôle (3) sont agencés pour gérer sensiblement simultanément au moins deux requêtes d'utilisateurs provenant d'au moins deux terminaux d'utilisateurs différents (T1 i).
12. Dispositif selon l'une des revendications 1 à 11 , caractérisé en ce que lesdits moyens de contrôle (3) sont agencés pour associer plusieurs fois un même module élémentaire à une même couche, selon des configurations éventuellement différentes, de sorte qu'ils puissent assurer des traitements en série ou en parallèle.
13. Dispositif selon l'une des revendications 1 à 12, caractérisé en ce que ledit serveur (1) dans lequel il est implanté est de type multitâches, et en ce que lesdits moyens de contrôle (3) sont agencés pour gérer la répartition de tâches de traitement au sein dudit serveur (1).
14. Dispositif selon l'une des revendications 1 à 12, caractérisé en ce qu'il est implanté dans au moins deux serveurs informatiques sous forme de parties complémentaires, et en ce que lesdits moyens de contrôle (3) sont agencés pour gérer la répartition de tâches de traitement entre lesdits serveurs.
15. Dispositif selon l'une des revendications 1 à 14, caractérisé en ce que lesdits moyens d'interfaçage de modules (5) fonctionnent selon le mode Java Management extension (JMX).
16. Dispositif selon l'une des revendications 1 à 15, caractérisé en ce qu'il comprend des moyens d'encapsulation (7) agencés pour adapter un module élémentaire reçu d'un serveur informatique (10) équipé d'un dispositif de traitement (20) d'un autre type, de sorte qu'il puisse fonctionner dans l'une au moins des couches de la structure (6).
17. Dispositif selon l'une des revendications 1 à 16, caractérisé en ce que certains au moins des modules élémentaires et/ou des modules auxiliaires et/ou des moyens de contrôle et/ou des moyens d'interfaçage sont des modules logiciels réalisés en langage informatique JAVA.
18. Dispositif selon la revendication 17, caractérisé en ce que ledit langage informatique est utilisé dans un mode de programmation de type non bloquant.
19. Dispositif selon l'une des revendications 1 à 18, caractérisé en ce que certains au moins des modules élémentaires et/ou des moyens de contrôle et/ou des moyens d'interfaçage sont des modules logiciels réalisés en langage informatique C ou C++.
20. Serveur informatique de type « proxy », caractérisé en ce qu'il comporte un dispositif de traitement (2) selon l'une des revendications précédentes.
21. Procédé de traitement de données, caractérisé en ce qu'il comprend les étapes suivantes : a) prévoir une structure (6) à couches logiques de bas niveau pour le traitement de données, comportant au moins une première couche (I) permettant d'initier des requêtes d'utilisateur à destination d'un réseau, une seconde couche (G) destinée à récupérer des flux de données transmis par ledit réseau en réponse à une requête initiée par la première couche (I), une troisième couche (T) destinée à transformer des données de flux récupérés, et une quatrième couche (S) destinée à transmettre à l'utilisateur requérant lesdites données transformées, b) prévoir une multiplicité de modules élémentaires agencés pour appliquer des traitements spécifiques à des flux de données entrant, selon leur type, et pour générer des flux de données sortant comportant lesdites données traitées, c) associer à l'une au moins des couches l'un au moins des modules en fonction d'une requête d'utilisateur, puis configurer chaque module associé à chaque couche de sorte qu'il puisse échanger des flux de données avec au moins un module de la couche qui suit la sienne et/ou au moins un autre module de sa couche, et d) adjoindre au flux de données sortant de chaque module élémentaire configuré et associé à une couche un objet requête, représentatif du type dudit flux sortant et s'enrichissant de couche en couche, de sorte qu'à réception de ce flux un module élémentaire récepteur puisse déterminer s'il doit traiter ledit flux ou le transmettre sans traitement à un autre module.
22. Utilisation du dispositif (2), du serveur proxy (1) et du procédé selon l'une des revendications précédentes, dans le domaine des réseaux de télécommunications choisis dans un groupe comprenant les réseaux publics et les réseaux privés.
23. Utilisation du dispositif (2), du serveur proxy (1) et du procédé selon l'une des revendications précédentes, pour la diffusion et la réception de données et d'applications vers des terminaux de données locaux ou distants connectés par des réseaux, du type réseaux filaires ou réseaux sans fil, en particulier pour des formations ou des réunions dont les participants sont équipés de terminaux de données connectés au serveur proxy (1) par un réseau sans fil.
PCT/FR2002/001443 2001-04-26 2002-04-25 Dispositif et procede de traitement de donnees, et serveur comportant ce dispositif WO2002089446A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0105649A FR2824214B1 (fr) 2001-04-26 2001-04-26 Serveur perfectionne de gestion de donnees entre un reseau et des terminaux d'utilisateur, et dispositif et procede de traitement de donnees associes
FR01/05649 2001-04-26

Publications (2)

Publication Number Publication Date
WO2002089446A2 true WO2002089446A2 (fr) 2002-11-07
WO2002089446A3 WO2002089446A3 (fr) 2003-01-30

Family

ID=8862736

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2002/001443 WO2002089446A2 (fr) 2001-04-26 2002-04-25 Dispositif et procede de traitement de donnees, et serveur comportant ce dispositif

Country Status (2)

Country Link
FR (1) FR2824214B1 (fr)
WO (1) WO2002089446A2 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5339392A (en) * 1989-07-27 1994-08-16 Risberg Jeffrey S Apparatus and method for creation of a user definable video displayed document showing changes in real time data

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5339392A (en) * 1989-07-27 1994-08-16 Risberg Jeffrey S Apparatus and method for creation of a user definable video displayed document showing changes in real time data

Also Published As

Publication number Publication date
FR2824214A1 (fr) 2002-10-31
WO2002089446A3 (fr) 2003-01-30
FR2824214B1 (fr) 2003-08-01

Similar Documents

Publication Publication Date Title
EP0951155A1 (fr) Procédé et système d'administration de réseaux et de systèmes
FR2801697A1 (fr) Procede d'acces selon divers protocoles a des objets d'un arbre representatif d'au moins une ressource de systeme
EP1507384A1 (fr) Procédé de masquage des traitements applicatifs d'une requete d'accès à un serveur et système de masquage correspondant
WO2005101739A1 (fr) Systeme et procede de controle d'equipements a distance a l'aide de commandes at, dispositif, module de radiocommunication et programme correspondants
EP1388058A1 (fr) Procede de communication et/ou de partage de ressources machines, entre une pluralite de membres d'une communaute, au sein d'un reseau de communication
WO2002001313A2 (fr) Procede de transmission d'un agent mobile dans un reseau; emetteur, recepteur, et agent mobile associes
EP1357724B1 (fr) Dispositif de gestion de filtres de données
FR2924241A1 (fr) Serveur de telechargement a deux ports et procede associe
WO2001024475A2 (fr) Procede et architecture de pilotage a distance d'une station d'utilisateur via un reseau de type internet
FR2737372A1 (fr) Dispositif et procede d'interconnexion de reseaux, routeur ip comprenant un tel dispositif
WO2007107674A2 (fr) Procede de communication de donnees entre des systemes de traitement heterogenes connectes en reseau local et systeme de communication mettant en oeuvre ce procede
WO2001005137A1 (fr) Gestion de telephones publics
WO2002089446A2 (fr) Dispositif et procede de traitement de donnees, et serveur comportant ce dispositif
FR2843847A1 (fr) Systeme permettant d'etablir une connexion telnet avec un dispositif eloigne depourvu de modem
FR2800224A1 (fr) Procede et systeme de mise en antememoire de donnees http transportees avec des donnees de socks dans des datagrammes ip
EP1933531B1 (fr) Dispositif de contrôle de communications sur IP entre des équipements de communication IP, avec prise de contrôle automatisée de leurs flux de média(s)
EP1432213B1 (fr) Plate-forme de médiation et réseau de transport de messages
FR2809255A1 (fr) Procede et appareil de fourniture et d'administration de services sur le reseau internet
EP1508998A1 (fr) Procédé et dispositif de génération de rôles pour des éléments d'un réseau de communications, à partir de modèles de rôles
EP1906625B1 (fr) Procédé et système de partage de fichiers sur un réseau, utilisant des capacités de stockage d'un boîtier de connexion au réseau
WO2002075546A2 (fr) Procede de sauvegarde et de restauration de l'ensemble des parametres de configuration d'une plateforme informatique par l'intermediaire d'un serveur
FR3091120A1 (fr) Procédé d’optimisation de l’utilisation de passerelles en fonction des messages à transmettre
FR2755521A1 (fr) Centrale domotique
WO2003101070A1 (fr) Protocole de communication entre un module d'application vocale et une plate-forme vocale dans un serveur vocal
FR2816416A1 (fr) Procede d'obtention de donnees par lots

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG US UZ VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
AK Designated states

Kind code of ref document: A3

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG US UZ VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: CONSTATATION DE LA PERTE D UN DROIT CONFORMEMENT AE LA REGLE 69 (1) CBE , 13-01-2004

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP