FR2806493A1 - METHOD FOR GRAPHIC PROGRAMMING - Google Patents

Abstract

Method for graphic programming consisting in storing, during the execution phase, in at least one memory of a server and in the memory of one or more clients, autonomous computer objects each comprising input interfaces and interfaces output to communicate with each other, the link between the input and output interfaces being established by a computer module generating the links from an entry, at least some objects being constituted by an autonomous computer module made up of two components, each of said components being indivisible and capable of exchanging information formed by digital data with the complementary component, one of said components being loaded into the RAM of the server and the other of said components being loaded into the RAM of the client, and in that a module is devoid of means for accessing another module.

Description

i

  METHOD FOR GRAPHIC PROGRAMMING

  The present invention relates to the field of computer architectures, and in particular a method for the development of applications intended for operation in

  network, for example on the Internet.

  The invention lies in the field of component graphics programming, allowing developers to use autonomous computer objects, and to manage their interactions using development tools implementing a graphical interface allowing automate the creation of procedures and

  inter-object communication files.

  A certain number of techniques today propose a concept of graphic programming based on independent modules: - we have a certain number of bricks (or modules) which, like an integrated circuit, present named inputs and outputs - each module has no knowledge of others - the development of an application consists of assembling any number of modules by connecting outputs to inputs this principle goes well with a graphical representation, so there are tools that allow the The user places modules on a "sheet", then draw arrows between these modules, from an exit to an entry. In addition, certain technologies present a distribution concept and therefore make it possible to distribute the modules over a set of machines. In this case, the module

  remains indivisible and is placed entirely on a machine.

  The object of the invention is to extend these techniques to websites in which visitors will be able to interact. In such a site, the processing is distributed between

the server and the clients.

  The server is the connection point of the site:

  this is the point to which we connect to enter the site.

  It is under the control of the site owner. Customers are users who connect remotely to the site: their machine is not under the control of the site owner, and yet it will participate in the operation of the

  site by performing part of the processing.

  The classic solution which consists in distributing modules finds limits here: - for a password entry system: - the client must display the entry interface, encrypt the password and transmit it to the server - the server receives the password, decrypts and verifies it - for a discussion system in a 3d environment: - the client calculates and displays an environment in 3 dimensions - the server informs each client of the presence of the others and possibly acts as a relay and

filter in discussions.

  Each functionality should therefore be divided into two heterogeneous objects: an object operating on the

  server, and an object running on clients.

  The communication that results between these two components of the same functionality would then become visible in the site creation tool, since it would be represented by links that would have no

  flexibility (there would be an obligation to trace them).

  We also recall the two communication principles: - selection principle: to whom do we want to send a message? - principle of translation: what do we want to mean, and how to make it understood? We know in the prior art different

  patents relating to such architectures.

  For example, European patent EP732834 describes a system and a method for determining and manipulating the configuration information of servers.

  in an environment of distributed objects.

  European patent EP546683 describes an object-oriented data processing system having a means for producing a loadable object module from an interface definition of objects independent of a language, comprising a storage means for storing the interface definition of objects independent of a language. Language links include a class data structure external to binary information, and means for compiling language links to produce a module

loadable object.

  Also known is the American patent US5915113 which describes an object-programming method which makes it possible to distribute computer objects and to create links between them. US patent US5724589 describes a graphical programming method in which computer objects

  are devoid of mutual knowledge.

  US patent US5991535 describes another

object programming process.

  The methods of the prior art all relate to methods in which the objects are loaded and executed either on the server or on a client station. This has several drawbacks. First of all, it is not possible to optimize client or server IT resources, because objects are necessarily executed on the machine on which they are loaded. On the other hand, the client computer accesses the objects at the time of their execution, and it is therefore not possible to

  preserve the confidentiality of these objects.

  The object of the invention is to remedy these drawbacks by proposing a method implementing objects which are dynamically divisible into two or more complementary modules, which are created and destroyed on the

client workstation dynamically.

  Complementary modules of the same object

  interact with each other by messages circulating on the network.

  The invention relates in its most general sense to a method for graphical programming consisting in storing, during the execution phase, in at least one memory of a server and in the memory of one or more clients of computer objects. autonomous each comprising input and output interfaces for communicating with each other, the connection between the input and output interfaces being established by a computer module generating the connections from a graphical input characterized in that certain at least objects are constituted by an autonomous computer module made up of two components, each of said components being indivisible and capable of exchanging information formed by digital data with the complementary component, one of said components being loaded into the RAM of the server and the other of said components being loaded into the customer's RAM, and in that q a module is devoid of means

to access another module.

  Each object can have a distributed operation: part of the processing is carried out on the server, and another part of the processing is carried out on the client. According to a variant, all of the computer objects and modules are stored, apart from the

  execution phases, only in the memory of the server.

  Advantageously, the objects made up of two complementary computer modules comprise a module transferred, at the time of their execution, in the memory of the client station and an additional module recorded only in the memory of the server, the two modules being able to exchange digital data by through a

  network on which the client and the server are connected.

  According to a preferred embodiment, the module saved in the client's memory is activated by instructions transmitted by the module saved in the

server memory.

  Preferably, the modules downloaded by the client are executable files, written in a

any computer language.

  According to a variant, the server module includes means for allowing the exchange of digital data between

  two modules downloaded by the client.

  According to a particular mode of implementation, the computer objects are recorded, before their execution, in several separate servers linked together by a

computer network.

  Advantageously, the computer data exchanged between the server (s), and the client (s) consists of a message comprising a client identifier

and possibly a parameter.

  Preferably, the loading into RAM of a module on the client station is controlled by the reception of a

  message containing the identifier of said module.

  The invention will be better understood on reading the

  description which follows, referring to examples of implementation

non-limiting work.

  The method according to the invention is based on the principle that a functionality must correspond to a single object, since it is easier for a non-technician to handle complete functionalities rather than bits of functionality. Each object is therefore presented as a box

  having inputs and outputs.

  Each functionality is broken down internally into at most two parts: - a part operating on the server - a part possibly operating on client workstations (this is not always required) This raises the question of the location of the inputs and outputs: each can be located on the

  server part or on the client part.

  A distinction is made between: - intra-object communication: a client part of an object communicates with the part

  server of the same module, or vice versa.

  - intra-object communication: a module communicates with another

Intra-object communication.

  The translation principle is as follows: the server and client parts of the same object are supposed to be

  know and therefore speak the same language.

  The principle of selection is simple in the client to server direction since there is only one part

server for a module.

  In the server to client direction, the selection principle involves choosing which client module to send to

the message.

  Inter-module communication The translation principle is solved by links: each link connects a named output and input, and therefore defines a correspondence between two names, which is the

translation clean.

  The selection principle is partially solved by the links: each link defines an emitting object and a

receiving object.

  The problem of locating the entry must still be resolved: - if the entry is on the server part of the receiving object, there is no question since the server part is unique - if the entry is on the client part of the receiving object, you must specify to which client the

message must be transmitted.

  User-Flow Graph As a result, messages must contain additional information, which turns out to be the information

  fundamental, namely the indication of a client.

  The site therefore consists of a static graph of

  modules, the mobile principle of which is customers.

  Customers are generalized to the concept of user. We associate a unique 'user' with each client and we distinguish: - the 'users' who correspond to a client - the 'users' who do not correspond to any client

  and who reside permanently in the server.

  We do not refrain from passing a 'user' from one state to another: the 'user' of a client remains in the system

  after disconnection, and is reassigned to the customer when the latter

here comes back.

  An inter-object message is defined as: - a 'user', which is the user directly concerned by the message, and which serves to resolve routing questions - possibly any parameter, allowing data flows between modules to be managed and not only signals, possibly a list of 'users' indirectly affected by the action, possibly a response function. Any object is authorized to send such messages on its outputs. The architecture according to the invention takes charge of this message and transmits it by following the links in the graph. Two types of module entries are defined: - a server entry: the server object takes care of messages arriving at this entry - a client entry: the client object normally takes care of messages which arrive at this entry. The server can also offer to support such an entry for 'users' who do not correspond to a client, as well as for 'users' who correspond to a client but for whom the client module has not been activated. routing rules: - message sent by a server module - message directed towards a server part: - no particular routing question - message directed towards a client part: - either the 'user' corresponds to a client, and then the message is sent to this client - either the 'user' does not correspond to a client, and then the message is nevertheless transmitted to the server. - message sent by a client module - Such a message necessarily references the

user 'associated with the client.

  - message directed towards a server part: - no particular routing question - message directed towards a client part: the message is transmitted locally Dynamic activation By the structure described above, it follows that the same graph is used on the server side and client side. We will talk about copy architecture. However, this copy is partial and dynamic: for reasons of efficiency and security, it is not useful that the client modules are all in operation at a given time with a given client. Certain parts of the site may

  indeed remain inaccessible to a client.

  The dynamic activation principle consists in letting each server module decide on the activation of the corresponding client module: it decides for itself

  activate / deactivate the client part for a given client.

  It is only at this moment that the client will become aware

of this part of the graph.

  Implementation of the method The method according to the invention allows the creation of Internet sites. The designer of the site defines an architecture by the selection of pre-existing objects and by the establishment of links between these objects. Each object manages one or more functionalities: log, authentication, 3D space, ... Each object can have a distributed operation: part of the processing takes place on the server, and another part of the

  processing takes place on the client.

  Each object is divided into two complementary parts, one of which works on the server and the other on the clients. The communication between the client part and the server part of the same object will be managed exclusively by the author of the module. Communication between two modules takes place exclusively in the form of links. The links are directional: from the event to the action. At any time, an object can trigger an event. The system converts it, according to the links, into actions for other modules. The module concerned by the action is informed of the identity of the issuer, and can respond to it, using

  the response function attached to the message.

  A site editor allows you to: - select the modules to integrate into the site - define the server and client documents - define the links between the objects - assign the zones to the modules: indicate in which zone to display the 3D, a button, an image - launch the module editors. Each module contains an editor which makes it possible to configure the module (define a 3D space for a 3D management module, define the texts of a "display banner" module, ...) The server plays the role of distributor of resources . A resource corresponds to a set of digital data. It belongs to an object which is its owner. Resources are the data that clients will be able to download: file containing the program of the

  client module, graphic file, 3D, sound, ...

  Each module records the resources that the client may need, in order to guarantee the possibilities of automatic updating. A resource is normally accessible to any client whose client module corresponding to the owner module is activated. However, the resource can be secured with access restricted to only authorized clients. On the server side, the resource can be present in the server memory or stored on the disk. In the first case only, it can be compressed before downloading by the client. In the second case, the data will be transferred directly: it is therefore recommended that the file is already compressed (file

jpeg graphics for example).

  On the client side, the resource can be stored in the cache under a given name which will make it possible, during later use, to determine whether the resource should be downloaded or whether it is present. The resource can also be supplied directly to the client, without going through storage on

a disk.

  The server calculates the signature of the resources that are submitted to it. This signature is transmitted to the client module when it is created. The client module checks the signature of the file bearing the name of the resource and whether it

  matches, it downloads the module again.

  The server can therefore: - save a resource by specifying its name and owner - deregister a resource by specifying its name deregister all the resources of a given owner

  - authorize a client to access a resource.

  The customer can: - request the download of a resource by knowing its name and specifying the nim of the requesting module, via the cache or not - stop the download of a resource - stop all downloads ordered by a

given module.

Claims (7)

  1 - Method for graphical programming consisting in storing, during the execution phase, in at least one memory of a server and in the memory of one or more clients, autonomous computer objects each comprising input interfaces and output interfaces for communicating with each other, the connection between the input and output interfaces being established by a computer module generating the connections from a graphic input characterized in that at least some objects are constituted by a computer module autonomous consisting of two components, each of said components being indivisible and capable of exchanging information formed by digital data with the complementary component, one of said components being loaded into the RAM of the server and the other of said components being loaded into the client's RAM, and that a module is devoid of resources to access another module.   2 - Method for graphical programming according to claim 1 characterized in that all of the computer objects and modules are stored, apart from the   execution phases, only in the memory of the server.   3 - Method for the graphical programming according to claim 1 or 2 characterized in that the objects made up of two complementary computer modules comprise a module transferred, at the time of their execution, in the memory of the client station and an additional module recorded only in the server memory, the two modules being capable of exchanging digital data via a network on which the client and server.   4 - Method for the graphical programming according to claim 3 characterized in that the module saved in the client's memory is activated by instructions   transmitted by the module saved in the server memory.   - Process for graphical programming according to   at least one of the preceding claims, characterized in   what modules downloaded by the client are files   executables written in any computer language.   6 - Process for graphical programming according to   at least one of the preceding claims, characterized in   what the server module includes means to allow the exchange of digital data between two downloaded modules by the customer.   7 - Process for graphical programming according to   at least one of the preceding claims, characterized in   what computer objects are saved, before their execution, in several separate servers linked together by a computer network.   8 - Process for graphical programming according to   at least one of the preceding claims, characterized in   that the computer data exchanged between the server (s) and the client (s) consists of a message comprising an identifier of a client and possibly a parameter. 9 - Method for the graphical programming according to the preceding claim characterized in that the loading into RAM of a module on the client station by the reception of a message comprising the identifier of said module. - Process for graphical programming according to   at least one of the preceding claims, characterized in   what an object consists of computer files   for the execution of a complete functionality.