FR 2923037 A1 20090501 FR 0758636 A 20071026 Procédé de réalisation d'un appel de procédure et produit programme d'ordinateur correspondant. 1 DOMAINE DE L'INVENTION L'invention concerne notamment le domaine des architectures d'applications informatiques. En particulier, l'invention concerne l'interopérabilité de composants logiciels en vue de la mise en oeuvre d'un service. De manière usuelle, des applications informatiques sont composées de plusieurs briques logicielles. Ainsi, il est fréquent de rencontrer des applications qui font appel à des composants applicatifs aptes à rendre un service donné. L'invention concerne l'architecture de telles applications et de tels composants applicatifs, encore appelés modules logiciels ou �plugins � dans la littérature. De manière générale, un �plugin� est un logiciel tiers venant s'interfacer à un logiciel principal afin de lui apporter de nouvelles fonctionnalités. Le logiciel principal fixe un standard d'échange d'informations auquel les plugins se soumettent. 2 SOLUTIONS DE L'ART ANTERIEUR Une application informatique, quels que soient les matériels et les systèmes d'exploitation utilisés est dans un premier temps construite, par le biais d'un langage idoine, puis le plus souvent compilée, c'est-à-dire transformée en un langage utilisable par le matériel et le système d'exploitation cible. Cette phase de compilation peut être réalisée préalablement à l'exécution de l'application ou directement lors de l'exécution : on utilise dans ce dernier cas un langage dit � interprété �. Les dernières évolutions en matière d'architecture et de conception d'applications ont conduit à l'avènement de plusieurs techniques, dont l'utilisation massive de langages par exemple dits � objets � et l'utilisation de plugins. Ces modules logiciels ne constituent généralement pas des applications à part entière, c'est-à-dire qu'ils ne sont pas aptes à être exécutés de manière autonome. Ils sont conçus pour rendre un service ou fournir une fonctionnalité à l'application qui les appelle. L'exécution de ce service ou de cette fonctionnalité peut, selon le matériel et les systèmes d'exploitation utilisés, soit être réalisée dans l'espace mémoire de l'application � appelante � (encore appelée application principale) soit être réalisée dans un espace mémoire différent, mais sur le même matériel, soit encore être réalisé sur un autre matériel auquel le matériel hébergeant l'application appelante est connecté. Ces techniques de l'art antérieur permettent ainsi de créer des applications à base de composants réutilisables. Il est ainsi possible de construire une application en référençant des composants logiciels existants et déjà compilés et de les utiliser au sein de la nouvelle application. L'application principale est compilée et les références aux composants logiciels à utiliser sont insérées dans le code compilé de l'application. Ainsi, une fonction spécifique d'un composant logiciel à utiliser au sein de l'application appelante dispose d'un point d'entrée, sous la forme d'une adresse mémoire, au sein même de l'application appelante compilée. Les techniques de l'état de l'art antérieur exigent que les plugins respectent une charte prédéfinie (sous la forme d'une interface binaire figée). Une telle charte assure que le plugin en question sera à même de répondre aux sollicitations de l'application. Elle est souvent matérialisée par l'obligation, pour le plugin, d'intégrer un certain nombre de fonctions (ou d'interfaces) qui sont attendues par l'application principale. De telles chartes sont cependant figées et le développement de plugin est donc contraint par ces chartes. Un inconvénient de ces techniques de construction et de ces architectures de l'art antérieur est lié à la phase de compilation qui permet de référencer (ou d'intégrer) directement (ou indirectement) les composants logiciels (ou leurs interfaces d'accès) au sein de l'application principale. En effet, cette intégration est figée par la compilation. Cela signifie que l'application principale en question intègre de manière fixe les références aux fonctions et aux procédures qui doivent être appelées, par exemple sous la forme d'adresses en mémoire. Ainsi par exemple, lorsqu'une application principale utilise un plugin qui dispose d'une interface vers trois fonctions fl, f2 et f3, chaque fonction est identifiée, au sein de l'application principale, par une adresse. Par voie de conséquence, lorsqu'une fonction du plugin est supprimée, que l'ordre des fonctions est modifié ou qu'une signature du plugin change, l'application doit être recompilée pour pouvoir fonctionner correctement. En effet, l'intégration d'un nouveau plugin sans nouvelle compilation entraîne au mieux une inexécution des fonctions modifiées et au pire un arrêt inopiné de l'application principale. Un autre inconvénient de cette technique de l'art antérieur est que les plugins sont la plupart du temps spécifiques à l'application pour laquelle ils ont été conçus. Ainsi, un plugin P d'une application A, fournissant certaines fonctionnalités, n'est généralement pas compatible avec une application B, à moins bien sur, tel que cela est pratiqué par l'homme de l'art, que l'application B soit spécifiquement conçue, à son tour, pour fonctionner avec ce plugin P, et donc avec les interfaces de plugin de l'application A. Ceci a pour conséquence directe de faire dépendre l'application B des choix qui ont été faits par l'application A lors de la définition des interfaces du plugin P et qui donc implicitement a pour effet d'établir une charte prédéfinie, tel que cela a été évoqué, et donc de limiter l'évolutivité des applications A et B. Ainsi, la technique connue d'utilisation de plugins selon l'art antérieur présente l'inconvénient que ces plugins sont spécifiques à l'application pour laquelle ils ont été conçus, et qu'on ne peut pas, en conséquence, réutiliser un plugin dans une application pour laquelle il n'a pas été initialement conçu. En outre, le mécanisme d'appel entre plugins et applications repose sur un appel de fonction/de méthode de manière directe. Si l'interface du plugin change (suite à l'ajout d'une nouvelle fonctionnalité, par exemple), l'application ne pourra plus l'utiliser, voire son exécution échouera ("arrêt inopiné" ou "blocage"). I1 faudra recompiler voire modifier l'application pour qu'elle puisse utiliser le plugin modifié. Un autre inconvénient de cet art antérieur est que le typage des interfaces, le système d'appel, ou le code du plugin peuvent différer d'un système d'exploitation à un autre, ce qui se traduit par du code qui ne peut pas être réutilisé tel quel sur différents OS. 3 RESUME DE L'INVENTION La solution proposée par l'invention ne présente pas ces inconvénients de l'art antérieur. Elle concerne en effet un procédé de réalisation d'un appel d'une procédure présente au sein d'au moins un premier module logiciel et requise par un second module logiciel, dit module logiciel appelant. Selon l'invention, un tel procédé met en oeuvre une méthode générique d'invocation de procédure, apte à appeler ladite procédure parmi une pluralité de procédures disponibles, en fonction d'un identifiant de ladite procédure à appeler, et il comprend : - une étape de construction d'une représentation spécifique dudit appel de 15 ladite procédure, sous la forme d'un ensemble structuré de données comprenant au moins ledit identifiant de ladite procédure ; - une étape de paramétrage de ladite méthode générique à partir de ladite représentation spécifique construite ; - une étape d'exécution de ladite méthode générique, entraînant la réalisation 20 dudit appel. Ainsi, l'invention permet de réaliser des appels à des procédures qui sont présentes dans des modules logiciels qui interagissent entre eux pour former une application informatique, sans qu'il soit nécessaire de définir une charte complexe ou des interfaces spécifiques. En effet, l'exécution d'une méthode générique 25 d'invocation de toutes les procédures présentes dans tous les modules logiciels de l'application garantit que l'appel à la procédure sera toujours correctement formé, quand bien même la procédure à invoquer n'existerait dans aucun module logiciel ou que les paramètres attendus pour cette procédure ne seraient pas ceux escomptés. L'invention permet donc également, par voie de conséquence, d'augmenter la portabilité des modules logiciels grâce à la construction d'une représentation spécifique de l'appel qui n'est pas mise en oeuvre dans les techniques de l'art antérieur. Dans l'art antérieur, un module logiciel, qui est par exemple créé pour rendre un service dans un environnement, par exemple de type �Linux � (Marque Déposée), attendra, lors de l'appel des procédures dont il est composé, des paramètres qui respectent les spécifications du système � Linux �. Comme les techniques de l'art antérieur sont basées sur la déclaration d'interfaces, la fourniture de ces paramètres est réalisée par le passage d'une référence ou d'une valeur dans un ou plusieurs processus d'exécution de l'application. Or une recompilation du module logiciel initialement prévu pour fonctionner sous � Linux � dans un environnement, par exemple de type � Windows � (marque déposée), n'a pas pour effet de modifier les interfaces d'appel aux procédures. Donc, les paramètres que l'application � Windows � passe au module logiciel recompilé sous � Windows � ont de fortes probabilités de ne pas convenir et d'entraîner un arrêt inopiné ou un blocage de l'application, du fait par exemple qu'une adresse mémoire (par exemple #01234567) n'est pas interprétée de la même manière pour � Windows � et pour � Linux �. De plus, si le module logiciel utilise des types qui sont spécifiques à un système d'exploitation, le code ne compilera pas sous un autre système d'exploitation. Avec le système de représentation d'appel s'appuyant uniquement sur un sous-ensemble restreint de types, le problème ne se pose plus. L'invention, de part la construction d'une représentation spécifique (sous la forme d'une structure de données) de l'appel de procédure certifie que même si les modules logiciels ont été conçus pour fonctionner dans un autre environnement, l'appel est tout de même réalisé, du fait de la formalisation des paramètres en structure de données. L'invention permet donc la réutilisation des modules logiciels. Selon un mode de réalisation particulier de l'invention, ledit procédé 30 comprend : - une étape de recherche dudit au moins un module logiciel possédant une référence à la procédure associée audit identifiant ; - une étape de déconstruction de ladite représentation spécifique dudit appel, fournissant au moins un paramètre d'appel ; - une étape d'exécution de ladite au moins une procédure à l'aide dudit au moins un paramètre d'appel. Ainsi, l'invention permet d'abstraire la connaissance des modules logiciels qui possèdent la procédure qui doit être exécutée. Il n'est donc plus nécessaire de connaître préalablement à l'appel le ou les modules qui � exportent �, par le biais d'une interface, la procédure à exécuter. Le procédé selon l'invention se charge de rechercher, parmi les modules chargés en mémoire celui ou ceux qui exportent la procédure à exécuter. Une fois que le ou les modules logiciels ont été localisés, le procédé selon l'invention procède à la déconstruction de la représentation d'appel ce qui permet de fournir des paramètres qui sont conformes, en terme de type, aux attentes de la procédure. L'exécution de la procédure est ensuite réalisée à l'aide des nouveaux paramètres d'appel formatés. Selon une caractéristique particulière de l'invention ledit procédé comprend : -une étape de construction d'une représentation spécifique d'au moins un résultat d'une exécution de ladite au moins une procédure ; - une étape de transmission de ladite représentation spécifique audit module logiciel appelant. Ainsi, l'invention permet également de simplifier la fourniture de résultats suite à l'exécution de la procédure. En effet, appliquant le principe de construction de représentation préalablement introduit, l'invention construit une représentation spécifique du résultat de l'exécution de la procédure qui est indépendant d'une adresse de référencement du résultat, tel que cela est le cas dans l'art antérieur. En effet, lors de l'utilisation d'interface d'appel de modules logiciels, les résultats fournis par la procédure sont également dépendants d'une adresse à laquelle le module logiciel appelant s'attend à recevoir les données d'un type particulier. L'invention contourne astucieusement cette limitation en construisant une représentation spécifique du résultat en la transmettant au module logiciel appelant. L'invention permet donc aux modules logiciels appelants et aux modules logiciels exécutants de s'abstraire totalement des interfaces requises par l'un et l'autre. Selon un mode de réalisation particulier de l'invention, ledit procédé de réalisation comprend : - une étape de déconstruction de ladite représentation dudit au moins un résultat, fournissant au moins un résultat formaté ; - une étape de traitement, par ledit module logiciel appelant, dudit au moins un résultat formaté. Ainsi, l'invention rend transparent le traitement des résultats de la procédure, et ce quel que soit le résultat renvoyé. En effet, dans l'hypothèse où la procédure renvoie un résultat qui ne correspond pas à celui qui serait attendu par le module logiciel appelant, l'invention permet d'isoler ces résultats inattendus en les fournissant sous un aspect formaté, plutôt que par une référence à une adresse. Ainsi, le module logiciel appelant n'est pas dans l'obligation de traiter tous les résultats de la procédure invoquée. En effet, si la procédure renvoie deux résultats, comme par exemple un entier et une chaîne de caractères alors que le module appelant s'attendait à recevoir un seul et unique entier, les techniques de l'art antérieur vont fournir, en tant que résultat de la procédure, une adresse où trouver un entier et la chaîne correspondante (par exemple sous la forme de pointeurs). L'invention, a contrario, fournit deux résultats formatés (respectant les attentes de celui qui appel en terme de type), dont un seul sera utilisé par le module appelant, ce qui garantit la stabilité de ce module appelant. Selon une caractéristique particulière de l'invention ledit au moins un paramètre d'appel est défini par : - un type appartenant à un ensemble de types prédéterminés ; - et une valeur. Ainsi, l'invention permet d'identifier, par un paramètre de la méthode générique d'invocation, la procédure à appeler et d'éviter par la suite un arrêt inopiné ou un blocage d'un module logiciel qui ne posséderait pas cette procédure. En effet, les modules logiciels auxquels il est fait appel sont aptes à reconnaître ou non le nom de la procédure qu'ils doivent mettre en oeuvre, ce qui permet ainsi d'éviter un appel d'une procédure inexistante et donc éviter un arrêt inopiné ou un blocage. Selon une caractéristique particulière de l'invention, ledit ensemble de types prédéterminés comprend au moins un des types de données appartenant au 10 groupe comprenant au moins : - Le type de ladite structure de données ; -le type entier ; - le type réel ; - le type caractère ; 15 - le type chaîne de caractère ; - le type booléen ; Ainsi, l'invention permet, grâce à l'utilisation de type prédéterminés qui sont identifiés dans la structure de données qui est utilisée pour l'appel à la procédure, d'assurer que les modules logiciels qui se communiquent l'appel de 20 procédure sont à même de comprendre la valeur du paramètre communiqué dans la structure de données en fonction de l'information de typage de ce paramètre. De plus, l'intégration, au sein de l'ensemble de types, du type � structure de données � utilisé pour l'appel générique assure que les modules logiciels qui échangent les structures de données pour les appels peuvent reconnaître la 25 structure de données qui leur est confié et en traduire le contenu (c'est-à-dire réaliser l'étape de déconstruction) pour lancer l'appel de la procédure. Selon une caractéristique particulière de l'invention, ledit au moins un résultat formaté est défini par : - un type appartenant à un ensemble de types prédéterminés ; 30 - et une valeur. Selon un autre aspect, l'invention concerne également un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, et comprenant des instructions de code de programme pour l'exécution du procédé de réalisation d'un appel tel que décrit précédemment. Encore selon un autre aspect, l'invention concerne un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution de la méthode générique tel que décrite précédemment. Selon un mode de réalisation particulier de l'invention, un tel produit programme d'ordinateur comprend : - des instructions de code de programme pour la mise en oeuvre une méthode générique d'invocation de procédure, apte à appeler ladite procédure parmi une pluralité de procédures disponibles, en fonction d'un identifiant de ladite procédure à appeler ; - des instructions de code de programme pour la construction d'une représentation spécifique dudit appel de ladite procédure, sous la forme d'un ensemble structuré de données comprenant au moins ledit identifiant 20 de ladite procédure ; - des instructions de code de programme pour le paramétrage de ladite méthode générique à partir de ladite représentation spécifique construite ; - des instructions de code de programme pour l'exécution de ladite méthode générique, entraînant la réalisation dudit appel. 25 4 LISTE DES FIGURES D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : 30 - la figure lA présente un synoptique d'un appel de procédure au sein d'un module logiciel selon les techniques de l'art antérieur ; - la figure lB présente un synoptique d'un appel de procédure au sein d'un module logiciel selon le procédé de l'invention ; - la figure 2 illustre un exemple d'appel dans un mode de réalisation particulier du procédé de l'invention. - la figure 3 illustre un exemple d'appel, dans un deuxième mode de réalisation particulier du procédé de l'invention. 5 DESCRIPTION DETAILLEE DE L'INVENTION 5.1 Rappel du principe de l'invention L'invention permet de répondre aux exigences contradictoires de flexibilité et de réutilisabilité des modules logiciels tout en garantissant une stabilité de fonctionnement optimale des applications informatiques qui font appel à ces mêmes modules logiciels. L'invention permet ainsi aux architectes et aux concepteurs d'applications d'utiliser des modules logiciels précompilés sans qu'il soit nécessaire, lors du développement de ces applications, de respecter une charte d'appel rigide ou d'importer toutes les interfaces des différents modules logiciels à utiliser dans l'application. On peut également noter que l'invention permet tout à la fois un appel de procédure qui se trouve dans un module logiciel par une application principale qu'un appel de procédure qui se trouve dans un autre module logiciel par un module logiciel. En d'autres termes, l'invention permet d'établir une plateforme commune d'appel de procédures, quel que soit l'endroit où elles sont situées dans l'espace d'exécution. On présente, en relation avec les figures lA et lB, une illustration des effets produits par l'invention. Dans les figures lA et lB, on présente une application informatique en cours d'exécution dans un espace mémoire 10 d'un système d'exploitation. Cet espace mémoire 10 comprend deux segments : un segment 11 contenant le code et réservé à l'exécution de l'application (à savoir l'applicatif principal ainsi que tous les modules chargés) et un segment 12 contenant les données et variables d'exécution. Ce segment d'exécution 11 comprend : - un module logiciel 13 qui contient le code de l'application principale, - et un module logiciel 14, contenant une procédure 15 qui implémente une fonctionnalité F particulière. Selon les techniques de l'art antérieur, succinctement représentées en figure lA, lorsque l'application principale 13 souhaite faire appel (131) à la procédure 15 du module logiciel 14, il utilise l'interface 16 d'appel de cette procédure, interface avec laquelle l'application principale 13 a été compilée. Cette interface 16 indique les paramètres à passer à la procédure 15 pour exécuter la fonctionnalité F. L'application principale 13 indique (132) au module logiciel 14, un emplacement en mémoire 17 dans le segment de données 12 où trouver le ou les paramètres nécessaires (les paramètres sont classiquement placés dans une pile d'exécution). La procédure 15 lit (151) alors ces paramètres 17 et s'exécute. Ainsi, par exemple, si le module logiciel 14 a été recompilé et que la procédure 15 attend non pas un mais deux paramètres et que l'application principale 13 n'a pas été recompilée avec la nouvelle interface du module logiciel 14, l'adresse indiquée (132) sera complétée au hasard par le système d'exploitation (ou l'environnement applicatif) par des informations (adresses, données, ...) fantaisistes pouvant entraîner une exécution erronée, un arrêt inopiné ou un blocage. Le principe de l'invention, est illustré en figure lB, dans laquelle un noyau 13b se place en coupure du code de l'application 13 et du module logiciel 14. Le principe de l'invention consiste dans un premier temps à construire (133), au travers du noyau 13b, une représentation 19 de l'appel à réaliser, c'est-à-dire de construire une structure de données à partir des paramètres 17. Ainsi, plutôt que de réaliser l'appel en empilant les paramètres sur une pile' d'exécution, on construit en mémoire une représentation spécifique formelle et typée de l'appel à réaliser, suivant une interface figée (c'est-à-dire par un appel à une fonction spécifique du noyau qui permet de créer la représentation) cette représentation étant une instance d'une structure générique de données (arbre, liste...). En d'autres termes, cette structure générique de données, selon l'invention, permet d'outrepasser l'appel classique qui a la forme d'un empilement de paramètres de la procédure. Cette représentation spécifique de l'appel porte en particulier les types et les valeurs des arguments de la procédure à appeler. Il s'agit donc d'une 5 représentation de l'appel sous la forme d'une structure de données. Selon l'invention, cette représentation spécifique sous la forme d'une structure de données est réalisée à l'aide d'un arbre typé et valué (qui comprend des valeurs), que l'on peut se représenter (pour une meilleure compréhension) sous forme d'un arbre XML. Cette structure de données comprend, selon l'invention, 10 au moins le nom (sous une forme valuée) de la procédure à appeler. La structure de données ne comprendra que le nom de la procédure à appeler dans le cas où cette procédure ne nécessite aucun paramètre. Il est bien évidemment possible d'utiliser d'autres structures de données pour le format de représentation des appels. 15 Les inventeurs ont eu l'ingénieuse idée d'utiliser ce principe de construction d'une structure de données pour modéliser l'appel à réaliser. Ainsi, la première étape de construction du procédé de l'invention construit (133) une représentation 19 des paramètres nécessaires à l'appel de la procédure 15. Cette construction s'accompagne également de l'insertion, dans la structure de données 20 19, du nom de la procédure 15 à appeler. La construction de la structure de données est ensuite astucieusement couplée à une invocation (134) d'une méthode d'appel générique 18 de procédure faisant office de lien générique avec le module logiciel 14 contenant la procédure 15. L'exécution (134) de la méthode d'appel générique 18 utilise la représentation 25 spécifique des paramètres 19. Selon les modes de réalisation de l'invention, la méthode d'appel générique peut par exemple transférer les paramètres 19 et laisser le module logiciel 14 extraire les paramètres en question et appeler la procédure 15. En d'autres termes, au lieu de placer les paramètres dans une pile, et de 30 pointer à l'adresse #XXX du module logiciel 14 pour appeler la procédure 15 souhaitée, on représente, selon l'invention, l'appel en mémoire, et on passe cet appel à une adresse #YYY (figée) du noyau 13b. Cette adresse #YYY est le point d'entrée qui est utilisé pour les invocations de procédure. Le noyau 13b se charge alors de retrouver le module logiciel 14 qui contient la procédure 15 et transmet la représentation spécifique de l'appel au module logiciel 14 afin que la procédure 15 soit exécutée. Le module logiciel 14 réalise ensuite une déconstruction de cette représentation et effectue (135), dans la mesure où il en est capable, l'appel de la procédure 15 qui met en oeuvre la fonctionnalité F. L'invention permet ainsi d'assurer une stabilité d'exécution des procédures, même si le module logiciel 14 ne connaît pas la procédure qu'on lui demande d'exécuter. En effet, l'étape de déconstruction permet au module logiciel 14 de vérifier s'il possède un point d'entrée pour la procédure 15 qu'on lui demande d'exécuter. Dans certains modes de réalisation, lorsque l'exécution de la procédure 15 du module logiciel 14 produit des résultats, ces résultats font également l'objet d'une construction d'une représentation spécifique, selon des principes similaires à la représentation spécifique d'appel, avant d'être transmis, par l'intermédiaire du noyau 13b, à l'application principale 13. L'application principale 13 réalise une déconstruction de la représentation spécifique des résultats et obtient les résultats formatés de l'exécution de la procédure 15. On entend par � résultat formaté � un résultat qui est dans un format attendu par celui qui a fait l'appel à l'origine, par exemple l'application principale 13. Un résultat formaté est donc conforme, en terme de type, à un type attendu par celui qui a fait l'appel à l'origine. Par la suite, on présente notamment un mode de réalisation dans lequel un module logiciel spécifique est chargé de réaliser une recherche des procédures au sein d'un ensemble de modules logiciels préalablement chargés au sein de l'espace mémoire de l'application. Il est clair cependant que l'invention ne se limite pas à cette application particulière, mais peut également être mise en oeuvre dans de nombreuses autres formes et plus généralement dans tous les cas où les avantages présentés par l'invention sont intéressants. 5.2 Description d'un mode de réalisation On présente dans ce mode de réalisation, une mise en oeuvre du procédé de l'invention basée sur l'utilisation d'un noyau applicatif. Dans ce mode de réalisation, la solution proposée s'appuie sur : - d'une part un "noyau" qui charge les modules logiciels, assure la communication entre ces modules logiciels et l'application, et permet la portabilité de l'ensemble ; - d'autre part, sur une création des représentations spécifiques des appels de procédure entre les modules logiciels et l'application. La solution proposée étend le principe du noyau applicatif au niveau du mécanisme d'appel de procédures (encore appelées méthodes ou fonctions) : les modules logiciels n'exposent pas une interface directement manipulée par l'application ou les autres modules logiciels. A la place, les appels sont modélisés par l'appelant avant d'être invoqués, 15 puis transmis au noyau, qui les interprète et retrouve la méthode à appeler dans le ou les modules logiciels correspondants, et réalise enfin l'appel. Cette mise en oeuvre de l'invention est basée sur quatre principes : l'appel par spécification, la constance des interfaces binaires, l'utilisation du noyau pour les appels, l'utilisation d'un format générique pour des "commandes" et des 20 "notifications". 5.2.1 Appel par spécification On distingue deux types d'appels : - Les "commandes" : ce sont les services offerts par un module logiciel (appels de procédure, méthode, fonction sur des modules logiciels). 25 L'application ou d'autres modules logiciels invoquent ces commandes pour demander au module logiciel de réaliser des traitements. - Les "notifications" : ce sont les évènements qu'un module logiciel ou qu'une application peut lever. L'application ou les autres modules logiciels s'abonnent à ces évènements (et sont donc qualifiés d'abonnés), et sont 30 notifiés par le module logiciel appelant lorsqu'il lève ces évènements. La notification est donc émise à l'application ou à d'autres modules logiciels lorsqu'un évènement particulier se produit. Selon l'invention, l'interface d'un module logiciel est définie par les commandes qu'il traite, et les notifications qu'il lève. Cette interface est définie, selon l'invention, par spécification, c'est-à-dire que l'appelant (le module logiciel ou l'application qui souhaite obtenir un service ou une fonctionnalité) n'a pas à connaître le format des commandes et des notifications pour pouvoir les invoquer de sorte que si l'appelant ne connaît pas parfaitement l'interface du module logiciel, l'appel à des fonctions contenues dans ce module n'entraîne pas l'arrêt inopiné ou le blocage de l'application. 5.2.2 Interfaces binaires constantes L'interface du noyau est composée, dans ce mode de réalisation, d'un ensemble de classes permettant de modéliser les appels de méthode ("commandes" et "notifications") et de réaliser les appels : il s'agit des APIs (de l'anglais � application programming interface � pour � interface de programmation d'application �) de commande et de notification. Selon l'invention, l'interface binaire des modules logiciels est composée uniquement d'un ensemble restreint de symboles (c'est-à-dire de fonctions/variables exportées par le module logiciel) permettant au noyau de charger le module logiciel, et de lui soumettre des commandes. Ces interfaces sont définies et n'évoluent pas. Le noyau et les modules logiciels ont donc une interface de programmation (API) et une interface binaire ABI (de l'anglais � application binary interface �) constantes. La construction des commandes et notifications par l'appelant s'appuie exclusivement sur les API exportées par le noyau (APIS de � commandes � et �notification �). Par définition, dans ce mode de réalisation de l'invention, l'appelant n'utilise aucune API des modules logiciels, mais uniquement celles du noyau, comme cela est expliqué ci dessous. Dans les mécanismes d'interfaces binaires figées selon l'art antérieur, l'interface des modules logiciels n'est pas retranscrite dans leur interface binaire. En d'autres termes, l'interface d'un module logiciel de l'art antérieur n'est pas connue de lui-même. Un module logiciel de l'art antérieur n'est pas à même de s'interroger lui-même pour savoir ce qu'il est capable de faire. L'invention pallie cet inconvénient de l'art antérieur, à l'aide d'au moins une interface binaire constante qui autorise un mécanisme de � questionnement �. Un tel mécanisme, selon l'invention, peut être mis en oeuvre de différentes manières, qui varient en fonction notamment des performances attendues de la part des modules logiciels. 5.2.3 Appels au travers du noyau Les commandes et les notifications sont créées par l'appelant (celui qui souhaite obtenir un service ou une fonctionnalité), puis transmises au noyau. Ce noyau trouve les modules logiciels capables de traiter la commande, ou les abonnés capables de traiter la notification, et leur soumet la commande et/ou notification pour effectuer les traitements adéquats. Un abonné est une application ou un module logiciel qui souhaite être informé d'un évènement par le biais d'une notification. L'abonné réalise donc un traitement lorsqu'il reçoit une notification. L'appel effectif de la procédure correspondant à une commande dans un module logiciel est réalisé par le module logiciel lui-même. En d'autres termes, le noyau transmet la commande au module logiciel qui � traite � cette commande et exécute la procédure qui y est associée. En d'autres termes, en utilisant les interfaces binaires constantes, on réalise une extraction à partir de la structure de données passée en paramètre et on procède, au sein même du module logiciel à un � questionnement � pour savoir si le module est apte à exécuter la fonction demandée (dont le nom est extrait de la structure de donnée d'appel). Si c'est le cas, alors le module appelle lui-même la fonction ou la procédure requise. L'appel réel de la fonction n'est donc pas réalisé par le module logiciel appelant (ou l'application appelante), mais par le module logiciel appelé. Suivant le même principe que pour les modules logiciels, dans lequel le 30 module appelle lui-même la procédure correspondant à une commande, les � callbacks � (codes exécutables passés en argument à un autre code exécutable) correspondant à une notification sont appelées par le � listener � (l'abonné qui attend la notification) lui-même. 5.2.4 Format des commandes et notifications Dans ce mode de réalisation, les commandes sont représentées par un "nom", identifiant unique parmi l'ensemble des commandes traitées, ainsi qu'une représentation spécifique des paramètres des commandes, et une représentation spécifique du résultat des commandes. Dans ce mode de réalisation, les paramètres et les résultats sont représentés en mémoire sous forme de structures de données arborescentes polymorphes (des arbres), à savoir que ces structures peuvent évoluer, sans qu'il soit nécessaire de procéder à une recompilation de l'application. L'organisation des arbres est laissée libre au développeur des modules logiciels, qui en définit la syntaxe et la sémantique pour chacune de ses 15 commandes dans la spécification du module logiciel. Les types supportés sont les types de base du langage (Entier, booléen, chaîne de caractère, .). Dans ce mode de réalisation, les différents types ne sont pas sérialisés. Cela signifie qu'ils ne sont pas convertis, et que leur représentation binaire en mémoire est conservée. Par exemple, l'entier 0x42 (32 bits) est stocké 20 sur 32 bits sous cette forme, et non converti en chaîne. Le procédé selon l'invention est ainsi plus performant. On présente, ci-dessous, un exemple d'une spécification de commande : Description de la commande : réalise une requête http GET in . [http_get url=string] [options] [timeout] unsigned int [/timeout] [/options] [/http_get] out . [http_get status=unsigned int] [body] string [/body] [/http_get] Nom de la commande : http_get Nombre d'arguments : 2 Argument 1 : url : URL de la requête http à réaliser (type : string) 25 30 35 Argument 2 : timeout : délai imparti pour la requête, en millisecondes (type : unsigned int) Résultat 1 : status : code de retour http (200, 404, .) (type : unsigned int) Résultat 2 : Contenu du body de la réponse (typiquement : page HTML) (type : string)...DTD: Dans ce mode de réalisation les notifications sont également représentées par un "nom", identifiant unique parmi l'ensemble des notifications traitées, ainsi qu'une série de zéro ou plusieurs arguments polymorphes. Le format des arguments est laissé libre au développeur du module logiciel, qui en définit la syntaxe et la sémantique pour chacune de ses notifications dans la spécification du module logiciel. Les types supportés sont les types de base du langage (Entier, booléen, chaîne de caractère, ...). Dans ce mode de réalisation, les différents types ne sont pas sérialisés. Exemple de spécification de notification : Description de la notification = notification indiquant un nombre de messages reçus Prototype : ( onMessagesReceived , unsigned short ) Nom de notification = "onMessagesReceived" Nombre d'arguments = 1 Argument 1 = le nombre de messages reçus (type : unsigned short) 5.2.5 Mise en oeuvre des principes On présente, en relation avec la figure 2, une illustration de la mise en oeuvre du procédé de l'invention pour appeler une procédure d'un module logiciel implémentant le protocole HTTP (le protocole HTTP n'est qu'un exemple de service pouvant être mis en oeuvre par un module logiciel). Dans ce mode de réalisation, une application 20 utilise un noyau 21 (sous la forme d'un module logiciel), qui présente à cette application une interface générique simplifiée (� CommandAPl � 210 et � ExecuteAPl � 211). Ce noyau 21 a également chargé des modules logiciels 300, 301 et 302, dont le module logiciel MLH 300 qui implémente le protocole HTTP. Ce module logiciel MLH 300 exporte une interface 3001 � ExécuteAPl � binaire constante. Il n'y a donc pas, comme dans les technique des l'art antérieur, une interface complexe. Les autres modules logiciels exportent également, selon l'invention, cette interface � ExecuteAPl �. Le module logiciel MLH 300 contient la procédure � http_get � 3002 qui exécute un GET sur une URL spécifiée. Cette procédure � http_get � 3002 n'est pas exportée par le module logiciel MLH 300. Dans ce mode de réalisation, l'enchaînement des actions conduisant à l'exécution de la procédure � httpget � 3002 par le module logiciel MLH 300 est le suivant : - L'appelant (ici, l'application) 20 construit (2001) la représentation spécifique de l'appel à réaliser, en s'appuyant uniquement sur la � CommandAPl � 210 du noyau 21. - La commande est transmise (2002) au noyau 21 au travers de son API d'exécution (� ExecuteAPl � 211). - Le noyau 21 trouve (2003), parmi les modules logiciels chargés 300, 301, 302, celui ou ceux qui traiteront la commande. - Le module logiciel MLH 300 identifie (2004) la méthode à appeler à partir de la commande reçue et réalise l'appel de la procédure � http_get � 3002. - Le module logiciel MLH 300 construit (2005) la représentation du retour de l'appel (le résultat de la commande) 3003, en s'appuyant uniquement sur l'interface � CommandAPl � 210 du noyau 21 qui renvoie (2005) le résultat. - Le module logiciel MLH 300 rend la main (2006, 2007) au noyau 21 qui rend lui-même la main (2008) à l'appelant 20. Celui-ci peut alors traiter le résultat. On présente ci-après un exemple de code (C++) de construction de la commande et d'analyse du résultat en utilisant la � CommandAPl � du noyau au sein de l'application appelante : // Creation de la commande mosaicnoyau::ICommand* pCommand = noyau::createNewCommand( "http get" ); // Construction de la representation de l'appel a realiser // Syntaxe definie dans la specification du plugin :30 // - Attribut url // - Sous noeud options/timeout noyau::INode* pParameter = pCommand->getParameter()->getRoot(); pParameter->setAttribute( "url", "http://mysite.com" ); noyau::INode* pOptions = pParameter->addSubNode( "options" ); noyau::INode* pTimeout = pParameter->addSubNode( "timeout" ); pTimeout->setValue( 500 ); // Execution de la commande pCommand->execute(); // Analyse du resultat // Syntaxe du resultat definie dans la specification du plugin : // - Sous noeud body noyau::INode* pResult = pCommand->getResult()->getRoot(); const char* zBody = pResult->getSubNode( "body" )->getValue(); Un tel code est inséré directement dans l'application appelante et permet la construction de la représentation spécifique de l'appel a réaliser, par l'intermédiaire d'un noyau applicatif (noyau) qui est à même de construire 20 directement la structure spécifique de données. Remarque : l'application du principe n'est pas détaillée ici pour les notifications, mais est très sensiblement identique. 5.3 Mise en oeuvre d'un masquage de la génération des représentations d'appel et de retour 25 Dans un mode de réalisation complémentaire de l'invention, plutôt que de laisser au module logiciel appelant (application appelante dans l'exemple précédent) la responsabilité de construire les arbres d'appel et la lecture des arbres résultats (commandes) ou l'analyse des n-uplets (notifications) comme cela est présenté ci-dessus, une technique d'encapsulation permet de masquer ces 30 opérations. Elle s'appuie sur la définition d'un ensemble de classes de commande (une par commande), décrites dans une série de fichiers d'entête (.h) uniquement, donc en code "inline", c'est-à-dire du code embarqué par l'appelant. Ce code s'appuyant lui-même sur la � CommandAPl � du noyau applicatif (noyau). 35 On présente ainsi, à titre d'exemple, un fichier �.h� (également appelé � helper �) définissant la commande � http_get �. Ce fichier est fourni avec le module logiciel (il s'agit donc d'un élément de l'interface du � plugin � définie par 10 15 spécification) et permet aux concepteurs d'applications � appelantes � de ne pas se soucier de la construction de la commande d'appel : // Classe Helper pour la commande http_get // Cette classe réalise elle-même les appels à la "Command API" du // noyau pour construire la représentation de l'appel, et // récupérer les résultats dans la représentation du retour de // la commande. class HttpGet : public noyau::ICommand { public: // Construction de la commande // On retrouve dans ces methodes le code de l'exemple // précédent HttpGet( const char* zUrl ) . Command( "http get" ) { getParameter()->getRoot()->setAttribute( "url", zUrl ); void setTimeout( unsigned int uiTimeout ) { noyau::INode* pOptions = pParameter->addSubNode( "options" ); noyau::INode* pTimeout = pParameter->addSubNode( "timeout" ); pTimeout->setValue( uiTimeout ); } public: // Récupértion du résultat // On retrouve dans ces methodes le code de l'exemple // précédent const char* getBody() { noyau::INode* pResult = pCommand->getResult()->getRoot(); return pResult->getValue(); } }; L'utilisation de cette classe d'encapsulation permet de simplifier et de fiabiliser l'appel à la commande � http_get � de l'exemple précédent à partir de 40 l'application appelante : // Creation de la commande HttpGet http_get( "http://mysite.com" ); http get.setTimeout( 500 ); // Execution de la commande http get.execute(); // Analyse du resultat 10 15 20 25 30 35 45 const char* zBody = http get.getBody(); Les deux exemples précédents sont strictement équivalents. Remarque : un mécanisme de masquage similaire est conçu pour les notifications (voir partie suivante). 5.4 Notifications 5.4.1 Généralités Les notifications constituent un deuxième mode de mise en oeuvre du principe d'appel de procédure selon l'invention. Les notifications représentent des évènements levés par les modules logiciels/l'application, à destination d'abonnés dans l'application/les modules logiciels. Lever une notification consiste à appeler la procédure (� callback �) associée à la notification dans tous les abonnés (� listeners �) présents dans l'espace d'exécution au moment de l'appel. 5.4.2 Similarités Les commandes et les notifications sont similaires dans le sens où toutes deux respectent les principes de base du procédé d'appel objet de l'invention : - l'appel de procédure est réalisé via un point d'exécution unique prenant en paramètre une représentation spécifique de l'appel à réaliser ; - une représentation de l'appel par spécification, incluant un typage des paramètres ; - une construction de la représentation spécifique de l'appel par du code embarqué dans l'appelant ; - un mécanisme de découverte des traitants, c'est-à-dire des modules et abonnés aptes à mettre en oeuvre la procédure demandée. Les différences entre les notifications et les commandes sont : - le format de la représentation spécifique de l'appel : dans une commande il y a deux arbres (un pour l'appel, un pour le résultat). Dans une notification on a un nom et une série de [0...n] arguments polymorphes (c'est-à-dire contenant une information de type) ; - Contrairement aux commandes, les notifications n'ont pas de valeur de retour ; - Le traitant : - pour une commande, le traitant est un module logiciel(s) ; - pour une notification, le traitant est un "abonné". Contrairement aux commandes, qui ne peuvent être traitées que par les modules logiciels, les notifications peuvent être traitées de n'importe où : les abonnés peuvent être créés indifféremment dans les modules logiciels ou l'application. 5.4.3 Format des notifications Une notification comprend une série de paramètres ordonnés. Le premier paramètre est le nom de la notification, identifiant unique parmi l'ensemble des notifications traitées. Suit une série de zéro ou plus arguments typés. Les types supportés pour les arguments sont les types primitifs du langage concerné C++ (int, bool, ...). Les arguments peuvent être passés par valeur (recopie en mémoire) ou par référence (par pointeur). Cette série de paramètres (nom+arguments typés) peut être assimilée à une représentation du prototype de la � callback � à appeler sur les abonnés. 5.4.3.1 Remarques : - dans ce mode de réalisation, les notifications n'ont pas de valeur de retour (elles sont toutes � void �). Mais rien n'empêcherait d'avoir une telle valeur dans un autre mode de réalisation. - dans ce mode de réalisation, les arguments peuvent être passés par référence. Ceci implique que les abonnés peuvent en modifier les valeurs pendant le traitement. Pendant le routage (c'est-à-dire la transmission en séquence de la notification), les abonnés suivants reçoivent les valeurs modifiées. - dans ce mode de réalisation, outre les types primitifs du langage, il est aussi possible de gérer les types du noyau (Typiquement : "arbre" ou "commande"). 5.4.3.2 Exemple de spécification de notification Description : notification indiquant un nombre de messages reçus Prototype : onMessagesReceived ( unsigned short, const char* ) Nom de notification = "onMessagesReceived" Nombre d'arguments = 2 Argument 1 = le nombre de messages reçus (type : unsigned short) Argument 2 = le nom de l'émetteur des messages (type : chaine de caractères) 5.4.4 Appel d'une notification Pour appeler une notification, le développeur doit construire la notification en s'appuyant sur la "Notification API" du noyau (mécanisme similaire à l'utilisation de � Command API � tel que précédemment décrit. Par exemple : // Variables locales unsigned short nb = 42; const char* from = "John Doe"; // Nous voulons lever la notification suivante : // onMessagesReceived( unsigned short ) Notification n( "msg received" ); // Nom de la notification n.addParameter( nb ); // ter argument : unsigned int n.addParameter( from ); // 2eme argument : const char* 25 Puis, il demande l'appel de la notification. Exemple : // Invocation de l'appel n.notify(); La notification est alors distribuée aux abonnés par le biais d'un 30 mécanisme de routage, dans lequel la notification passe d'abonné en abonné. 5.4.5 Masquage de la construction de la représentation De même que l'on a réalisé des "helpers" (c.f. 5.3) permettant de masquer à l'utilisateur la construction d'une commande par code � inline �, il est également possible de réaliser des � helpers � de notification. 35 Mais étant donné que les � helpers � sont destinés aux personnes (c'est-à-dire aux programmeurs et concepteurs) utilisant les modules logiciels, et que les notifications sont quasiment toujours levées depuis les modules logiciels (et donc20 de la responsabilité du développeur), de tels � helpers � de notification ne sont pas nécessaires en tant que tels dans ce mode de réalisation de l'invention. 5.4.6 Gestion des abonnés Les abonnés sont des objets implémentant une interface d'écoute 5 particulière pour pouvoir être notifiés. Le mécanisme mis en oeuvre s'appuie sur deux interfaces : - une interface de �listener � générique, permettant de déclarer l'objet au noyau. Lorsqu'un tel objet est instancié, le noyau sait qu'il faudra qu'il lui distribue des notifications, mais à ce niveau on ne sait pas encore 10 lesquelles. Réciproquement, lorsque l'objet sera détruit, le noyau sera informé qu'il ne faudra plus donner de notifications à cet objet. - une interface de � listener � spécifique à un ensemble de notifications, permettant de savoir quelles notifications doivent être traitées par l'objet (mécanique "d'introspection"), et réalisant l'appel de procédure. 15 La première interface est fournie par le noyau (API binaire classique). Par analogie aux commandes, il s'agit ici de l'équivalent de l'interface de "module", point d'entrée du module logiciel pour l'exécution de commandes. La deuxième interface hérite (au sens objet du terme) de la première interface. Elle ne contient que des méthodes virtuelles ou abstraites (les callbacks 20 de notification) et du code embarqué dans l'appelant (la "notification map"). Cette interface est fournie/réalisée par le développeur du module. De même que le développeur d'un module logiciel doit renseigner une "command map" pour indiquer quelles commandes son module logiciel va traiter, il doit également réaliser une ou plusieurs "interfaces de notification". 25 Les interfaces de notifications contiennent une "notification map" permettant d'aiguiller l'appel de notification vers la bonne méthode (virtuelle, et généralement abstraite) de l'objet implémentant l'interface de notification. Exemple d'interface de � listener � correspondant à l'exemple précédent : class IMessageListener : // Interface 2 : 30 // interface spécifique de notification public noyau::INoyauListener // Interface 1 : // interface générique // d'abonnement { public: // Callback correspondant à la notification "msg received" virtual void onMessagesReceived( unsigned short nbmsg, const char* from ) = 0; // Map associant des notifications aux callbacks correspondant // Le chiffre à la fin de NOYAU NOTIFICATION indique le nombre // d'arguments dans la notification BEGIN NOTIFICATION MAP NOYAU NOTIFICATION 2( "msg received", onMessagesReceived ) END NOTIFICATION MAP }; On note qu'il est possible de déclarer plusieurs notifications dans la 20 � notification map �. 5.4.7 Création d'abonnés Pour recevoir une ou plusieurs notifications, le développeur doit créer des objets héritant de l'interface de notifications désirée (la deuxième interface � listener � spécifique). 25 Exemple : class MonMessageListener : // Classe d'objet voulant recevoir // la notification public IMessageListener // Interface 2 : interface spécique // de notification { public: // Surcharge de la méthode abstraite // L'implémentation de la callback peut bien sûr être // réalisée dans un .cpp void onMessagesReceived( unsigned short nbmsg, const char* from ) { cout � nbmsg � " reçus de " � from � endl; } }; On précise que : 45 - il est possible d'implémenter plusieurs interfaces de notification dans un même objet. 10 15 30 35 40 il est possible d'instancier plusieurs fois le même objet, chaque instance étant bien sûr indépendante des autres instances. Lorsque ces objets sont instanciés, une interface (spécifique) d'abonnement/désabonnement est créée, et réalise l'abonnement auprès du noyau. 5 L'objet est maintenant prêt à recevoir les notifications. Réciproquement, lorsque l'objet sera détruit, l'interface (spécifique) d'abonnement / désabonnement avertira le noyau que l'objet ne devra plus recevoir les notifications. Exemple : // Création d'un objet MonMessageListener // L'objet est automatiquement abonné aux notifications de IMessageListener m pMonMessageLister = new MonMessageListener; // A partir d'ici, l'objet m pMonMessageListener est susceptible // de recevoir les notifications définies dans IMessageListener // Destruction de l'objet MonMessageListener // Les notifications ne seront plus distribuées à cette instance delete m pMonMessageLister; Il est bien sur possible de créer autant d'objets � MonMessageListener � que souhaité. 5.4.8 Déroulement d'une notification 25 On présente, en relation avec la figure 3, la mécanique d'abonnement et d'appel de notification dans ce mode de réalisation de l'invention. Dans ce mode de réalisation, une application 30 utilise un noyau 31 (sous la forme d'un module logiciel), qui présente à cette application une interface générique simplifiée (� ListenerAPl � 310 et � NotificationAPl � 311 et 30 �NotifyAPl � 312). Ce noyau 31 a également chargé un module logiciel 300 qui implémente une notification. Ce module logiciel 313 utilise (313-1) l'API � NOtificationAPl � 311 pour construire la notification. Puis il utilise (313-2) l'API �NotifyAPl � pour notifier l'événement (lever la notification). Il n'y a donc pas, comme dans les techniques de l'art antérieur, une interface complexe. 35 Dans cet exemple, les � listeners � 3001 sont créés (301-1) par l'application 30 (ils peuvent aussi être créés par d'autres modules logiciels), et la 10 15 20 notification est levée (313-2) par le module logiciel 313 (ce qui est le cas le plus fréquent, mais l'application peut elle aussi lever des notifications). Dans ce mode de réalisation, l'enchaînement des actions conduisant à la notification (313-2) de l'événement par le module logiciel 313 est le suivant : - Des abonnés 301 sont créés dans l'espace d'exécution (dans l'application ou dans des modules logiciels). Les abonnés s'enregistrent (301-1) au noyau par le biais de l'interface générique de � listener � du noyau (� Listener API � qui est une interface de programmation binaire). - Le module logiciel appelant 313 construit (313-1) la notification à réaliser, en s'appuyant uniquement sur la � NotificationAPl � du noyau. Cette API (binaire) exporte les classes et procédures permettant de représenter la notification. - La notification est transmise (313-2) au noyau au travers de son API de routage de notifications (� NotifyAPl �). Il s'agit d'une procédure exportée par le noyau (API binaire). - Le noyau découvre (313-3) les abonnés 301 à cette notification et leur transmet séquentiellement pour traitement. Si la notification est présente dans la � notification map � de l'abonné, l'abonné réalise alors l'appel à la callback correspondant à la notification.20 REVENDICATIONS 1. Procédé de réalisation d'un appel d'une procédure présente au sein d'au moins un premier module logiciel et requise par un second module logiciel, dit module logiciel appelant, caractérisé en ce qu'il met en oeuvre une méthode générique d'invocation de procédure, apte à appeler ladite procédure parmi une pluralité de procédures disponibles, en fonction d'un identifiant de ladite procédure à appeler, et en ce qu'il comprend : - une étape de construction d'une représentation spécifique dudit appel de ladite procédure, sous la forme d'un ensemble structuré de données comprenant au moins ledit identifiant de ladite procédure ; une étape de paramétrage de ladite méthode générique à partir de ladite représentation spécifique construite ; - une étape d'exécution de ladite méthode générique, entraînant la réalisation dudit appel. 2. Procédé de réalisation d'un appel selon la revendication 1, caractérisé en ce qu'il comprend : - une étape de recherche dudit au moins un module logiciel possédant une référence à la procédure associée audit identifiant ; - une étape de déconstruction de ladite représentation spécifique dudit appel, fournissant au moins un paramètre d'appel ; - une étape d'exécution de ladite au moins une procédure à l'aide dudit au moins un paramètre d'appel. 3. Procédé de réalisation d'un appel selon l'une quelconque des revendications 1 et 2, caractérisé en ce qu'il comprend : une étape de construction d'une représentation spécifique d'au moins un résultat d'une exécution de ladite au moins une procédure ; une étape de transmission de ladite représentation spécifique audit module logiciel appelant. 4. Procédé de réalisation d'un appel selon la revendication 3, caractérisé en ce qu'il comprend : - une étape de déconstruction de ladite représentation dudit au moins un résultat, fournissant au moins un résultat formaté ; - une étape de traitement, par ledit module logiciel appelant, dudit au moins un résultat formaté. 5. Procédé de réalisation d'un appel selon la revendication 2, caractérisé en ce que ledit au moins un paramètre d'appel est défini par : - un type appartenant à un ensemble de types prédéterminés ; - et une valeur. 6. Procédé de réalisation d'un appel selon la revendication 4, caractérisé en ce que ledit au moins un résultat formaté est défini par : un type appartenant à un ensemble de types prédéterminés ; - et une valeur. 7. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution du procédé de réalisation d'un appel de procédure selon l'une au moins des revendications 1 à 6, lorsqu'il est exécuté sur un ordinateur. 8. Produit programme d'ordinateur selon la revendication 7, caractérisé en ce qu'il comprend : des instructions de code de programme pour la mise en oeuvre d'une méthode générique d'invocation de procédure, apte à appeler ladite procédure parmi une pluralité de procédures disponibles, en fonction d'un identifiant de ladite procédure à appeler, et en ce qu'il comprend : des instructions de code de programme pour la construction d'une représentation spécifique dudit appel de ladite procédure, sous la forme 30 d'un ensemble structuré de données comprenant au moins ledit identifiantde ladite procédure ; - des instructions de code de programme pour le paramétrage de ladite méthode générique à partir de ladite représentation spécifique construite ; des instructions de code de programme pour l'exécution de ladite méthode générique, entraînant la réalisation dudit appel.